ETSITS101 725V7.3.0 



(2001-06) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+); 

Location Services (LCS); 

Mobile radio interface layer 3 

Location Services (LCS) specification 

(3GPP TS 04.71 version 7.3.0 Release 1998) 



3!^^ 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 




3GPP TS 04.71 version 7.3.0 Release 1998 1 ETSI TS 101 725 V7.3.0 (2001-06) 



Reference 



RTS/TSGG-020471 Q7R3 
Keywords 



GSM 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 

Siret N°348 623 562 00017 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at http://www. etsi . o rq/tb/status/ 

If you find errors in the present document, send your comment to: 
editor@etsi.fr 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2001. 
All rights reserved. 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 2 ETSI TS 101 725 V7.3.0 (2001-06) 



Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by the ETSI 3' Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/kev . 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 3 ETSI TS 101 725 V7.3.0 (2001-06) 



Contents 



Intellectual Property Rights 6 

Foreword 6 

1 Scope 7 

2 References 7 

3 Abbreviations 7 

4 Generic procedures for the control of location services 8 

4.1 Overview of the generic protocol and its scope 8 

4.2 Functional procedures for the control of location services 8 

4.2.1 General 8 

4.2.2 Common Information Element Category 8 

4.2.3 Location service procedures 8 

4.2.3.1 Introduction 8 

4.2.3.2 Handling of protocol errors in LCS procedures 9 

4.2.3.3 Handling of other errors in LCS procedures 9 

4.2.4 Multiple location service invocations 9 

4.2.5 Recovery procedures 9 

4.2.6 Generic protocol error handling for the component part of location services operations 9 

4.2.6.1 Single component errors 9 

4.2.6.2 Multiple component errors 10 

5 Location service support procedures 10 

5.1 General 10 

5.2 Location service support establishment 10 

5.2.1 Location service support establishment at the originating side 10 

5.2.2 Location service support establishment at the terminating side 10 

5.3 Location service support information transfer phase 10 

5.4 Location service support release 10 

5.5 Recovery procedures 11 

5.6 Message flow (single operation example) 11 

5.6.1 LMU initiated location service transaction 11 

5.6.2 Network initiated location service transaction 12 

5.7 Handling of unknown, unforeseen, and erroneous protocol data 12 

5.7.1 General 12 

5.7.2 Message too short 13 

5.7.3 Unknown or unforeseen transaction identifier 13 

5.7.4 Unknown or unforeseen message type 13 

5.7.5 Non-semantical mandatory Information Element Error 13 

5.7.6 Unknown and Unforeseen lEs in the non-imperative part 14 

5.7.6.1 lEIs unknown in the message 14 

5.7.6.2 Out of sequence lEs 14 

5.7.6.3 Repeated lEs 14 

5.7.7 Non-imperative message part errors 14 

5.7.7.1 Syntactically incorrect optional lEs (other than Facility) 14 

5.7.7.2 Conditional IE errors 14 

6 Message functional definitions and contents 15 

6.1 General 15 

6.2 Messages for location services control 15 

6.3 Facility 16 

6.4 Register 16 

6.4.1 Register (network to LMU direction) 16 

6.4.2 Register (LMU to network direction) 17 

6.5 Release complete 17 

6.5.1 Cause 17 

6.5.2 Facility 17 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 4 ETSI TS 101 725 V7.3.0 (2001-06) 

7 General message format and information elements coding between LMU and MSC 18 

7.1 Overview 18 

7.2 Protocol discriminator 18 

7.3 Transaction identifier 18 

7.4 Message type 18 

7.5 Facility information element 19 

7.6 Release forbidden 19 

8 General message format and information elements coding between LMU and SMLC 19 

8.1 Transparent LCS Information 19 

8.1.1 Operation Code 20 

8.1.2 Error Code 20 

8.1.3 Problem Code 21 

9 LMU LCS Protocol operation specifications 21 

9.1 General 21 

9.2 Operation types 22 

9.2.1 Operation types description 24 

9.2.1.1 StartRlT (network -> LMU) 25 

9.2.1.2 ReportRlT (LMU -->network) 25 

9.2.1.3 StopRlT (network -> LMU) 25 

9.2.1.4 IndicateRITError (LMU --> network) 25 

9.2.1.5 PerformTOA (network -> LMU) 25 

9.2.1.6 StatusQuery (network --> LMU) 25 

9.2.1.7 StatusUpdate (LMU --> network) 25 

9.2.1.8 ResetRequest (network --> LMU) 25 

9.2.1.9 OMMngrRequest (network --> LMU) 25 

9.2.1.10 OMAgntRequest (LMU -> network) 25 

10.3 Error types 26 

10.3.1 Error types ASN.l specification 26 

10.3.2 Error types description 26 

10.3.2.4 SystemFailure 26 

10.3.2.5 DataMissing 26 

10.3.2.6 UnexpectedDataValue 26 

10.3.2.7 ResourcesNotAvailable 26 

10.3.2.9 UnDefinedError 26 

10.4 Operations and errors implementation 27 

11 LMU LCS Protocol (LLP) messages 28 

11.1 Messages, data types and identifiers 28 

11.1.1 General 28 

11.1.2 ASN.l datatypes 28 

11.1.3 Identifiers definition 36 

Annex A (informative): RIT messages 37 

A.l Introduction 37 

A.2 Messages 37 

A.2.1 RIT Measurement Request Message 37 

A.2. 1.1 RIT Measurement Request Message Information Elements 37 

A.2.1. 1.1 Message Type IE 37 

A.2. 1.1. 2 Measurement Instructions IE 37 

A.2.1. 1.3 BTSListlE 39 

A.2.2 RIT Measurement Response Message 40 

A.2. 2.1 RIT Measurement Response Message Information Elements 40 

A.2.2. 1.1 Message type IE 40 

A.2.2. 1.2 RIT Measurement IE 40 

A.2.3 RIT Measurement Stop Message 44 

A.2. 3.1 RIT Measurement Stop Message Information Elements 44 

A.2.3. 1.1 1 Message type IE 44 

A.2.4 RIT Measurement Error Message 45 

A.2.4.1 RIT Measurement Error Message Information Elements 45 

A.2.4. 1.1 Message type IE 45 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 5 ETSI TS 101 725 V7.3.0 (2001-06) 

A.2.4.1.2 RIT Error Type IE 45 

A.2.4.1.3 RIT Error IE 45 

Annex B (informative): TOA messages 46 

B.l Messages 46 

B.1.1 Perform TOA Measurement Message 46 

B.l. 2 TOA Measurement Result Message 46 

B.2 Information element encodings 47 

B.2.1 Message Type IE 47 

B.2. 2 Measurement Device Info IE 47 

B.2. 3 Channel Description IE 47 

B.2.4 Signal Description IE 48 

B.2. 5 Timing Description IE 49 

B.2. 6 Measurement Options IE 51 

B.2. 7 Number of Measurement Devices IE 51 

B.2.8 Timing Info IE 51 

B.2. 10 Measurement Device ID IE 52 

B.2. 11 Measurement Info IE 52 

B.2.12 Number of Peaks IE 53 

B.2.13 Measured TOA IE 53 

B.2.14 TOA Quality IE 53 

Annex C (informative): Status Messages 54 

C.l Introduction 54 

C.2 Messages 54 

C.2.1 Status Query Message 54 

C.2. 1.1 Status Query Message Information Elements 54 

C.2.1. 1.1 Message Type IE 54 

C.2.2 Status Query Result Message 54 

C.2. 2.1 Status Query Result Message Information Elements 54 

C.2.2.1.1 Message Type IE 54 

C.2.2.1.2 Time IE 54 

C.2.2.1.3 RIT Status IE 55 

C.2.2.1.4 TOA Status IE 55 

C.2.2.1.5 O&M Status IE 55 

C.2.3 Status Update Message 55 

C.2. 3.1 Status Update Message Information Elements 56 

C.2.3. 1.1 Message Type IE 56 

C.2.3. 1.2 Reason for Status Update IE 56 

Annex D (informative): Change History 57 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 6 ETSI TS 101 725 V7.3.0 (2001-06) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
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Foreword 

This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document defines the coding of information necessary for support of location service operation on the 
mobile radio interface layer 3 within the digital cellular telecommunications system. 

The contents of the present document are subject to continuing work within SMG and TlPl and may change following 
formal SMG and TlPl approval. Should SMG or TlPl modify the contents of the present document it will then be 
re-issued with an identifying change of release date and an increase in version number as follows: 

Version 7.x.y 

where: 

7 GSM Phase 2+ Release 1998; 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc.; 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 7 ETSI TS 101 725 V7.3.0 (2001-06) 



Scope 



The present document contains the coding of information necessary for support of location service operation on the 
mobile radio interface layer 3. 

Clause 4 defines generic procedures for the control of location services. In clause 5 location service support procedures 
are defined. Clause 6 gives the functional definitions and contents of messages for location service operations. Clause 7 
gives the general format and coding for messages used for location service and the format and coding of information 
elements used for location service operations between the LMU and MSC. Clause 6 gives the general message format 
and information elements coding between the LMU and SMLC. 

Clause 8 gives the specification of the LMU LCS Protocol (LLP) operations. In clause 9 LMU - SMLC messages, data 
types and identifiers are given. 

This version does not support segmentation of messages. 
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4 Generic procedures for the control of location 

services 

4.1 Overview of the generic protocol and its scope 

One generic protocol is defined for the control of location services at the radio interface. This protocol operates at layer 
3 of the radio interface and assumes the use of layers 1 and 2 conform to 3GPP TS 05-series and 3GPP TS 04.04, 
3GPP TS 04.05 and 3GPP TS 04.06. The generic protocol uses the acknowledged information transfer service available 
at the layer 2 - layer 3 interface. 

The Functional protocol is based on the use of the Facility information element and the FACILITY message as well as 
other specific functional messages specified in this specification. 

4.2 Functional procedures for the control of location services 

4.2.1 General 

This clause specifies the functional signalling procedures for the control of location services at the radio interface. 

The functional protocol utilizes functions and services defined in 3GPP TS 04.08 and the functions of the data link layer 
as defined in 3GPP TS 04.06. This protocol utiUzes also definitions in 3GPP TS 04.07. 

The Common Information Element Category utilizes the Facility information element to transport the protocol defined 
in this specification. The use of the Facility information element is common to many services, and its contents indicates 
what type of procedure is being requested. This category can be signalled both in the LMU to network and the network 
to LMU directions. 

The correlation of location service operations and their responses, is provided by the combination of the transaction 
identifier of the messages containing the Facility information element and the Invoke identifier present within the 
Facility information element itself. 

4.2.2 Common Information Element Category 

The Common Information Element Category uses operations defined in this specification for location services 
signalling. Procedures are initiated by sending an operation including an invoke component. The invoke component 
may yield a Return Error, Return Result or Reject component (also included in an operation) depending on the outcome 
of the procedure. 

The operation state machines, and procedures for management of Invoke IDs specified in CCITT Recommendation 
Q.774 White Book are used. 

A REGISTER message, a FACILITY message or RELEASE COMPLETE message is used to carry the Facility 
information element which includes these operations. These operations request, acknowledge or reject the desired 
location service procedure. 

4.2.3 Location service procedures 
4.2.3.1 introduction 

For location service procedures independent of any call, the initiating side must establish a MM-connection between the 
network and the LMU according to the rules given in 3GPP TS 04.07 and 04.08. The LMU or the network starts the 
transaction by transferring a REGISTER message across the radio interface. This transaction is identified by the 
transaction identifier associated with the REGISTER message present in the component part of the Facility information 
element. Following the REGISTER message one or more FACILITY messages may be transmitted, all of them related 
by the use of the same transaction identifier. If the transaction is no longer used, it shall be released by sending a 
RELEASE COMPLETE message. This procedure is specified in detail in clause 5, and the text in clauseS takes 
precedence over this introduction. 
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To convey the location service invocation, the Facility information element is used. The Facility information element 
present either in the REGISTER message or a subsequent message identifies the location service involved and the type 
of component (i.e. Invoke, Return result. Return error or Reject component). 

When the REGISTER or FACILITY message contains a Facility information element and the requested service is 
available, a FACILITY message containing a Facility information element may be returned. One or more exchanges of 
FACILITY messages may subsequently occur. To terminate the service interaction and release the transaction identifier 
value, a RELEASE COMPLETE message is sent as specified for the specific location service procedure. The 
RELEASE COMPLETE message may also contain the Facility information element. 

4.2.3.2 Handling of protocol errors in LCS procedures 

Messages containing a Facility information element shall be checked for protocol errors before the contents of the 
Facility IE is acted on. The checks shall be performed in the following order: 

1) The message carrying the Facility IE shall be checked for protocol errors as specified in subclause 3.7. If a 
protocol error is found then the procedures in subclause 5.7 apply. 

2) The contents of the Facility IE shall be checked for protocol errors as specified in subclause 4.2.6. If a protocol 
error is found then the procedures in subclause 4.2.6 apply. 

4.2.3.3 Handling of other errors in LCS procedures 

If the tests specified in subclause 4.2.3.2 have been passed without the detection of a protocol error, the receiver will 
attempt to process the contents of the Facility Information Element. If errors occur during this processing (e.g. system 
failure, or information in the Facility IE is incompatible with the requested operation) then the procedures specified in 
the individual service specifications apply. 

An example of the behaviour that could occur in this case is: 

the LMU or network sends a Facility information element containing a return error component in a FACILITY 
or RELEASE COMPLETE message. If the FACILITY message is used then the MM Connection may continue 
to be used for further signalling. 

4.2.4 Multiple location service invocations 

It is possible for several LCS transactions to be used simultaneously. LCS transactions can also exist in parallel with 
other CM -Layer and MM transactions. The handling of multiple MM connections is defined in 3GPP TS 04.07 and 
04.08. 

A single Facility Information Element shall not contain more than one component. 

4.2.5 Recovery procedures 

In case a transaction is not terminated according to the normal procedure as described in this specification the network 
side has to ensure that the transaction is terminated e.g. by a supervision timer. 

4.2.6 Generic protocol error handling for the component part of location 
services operations 

If a location service operation is to be rejected the operation will be denied, and provided the transaction is still in 
progress, an appropriate reject component will be returned in a Facility Information Element. 

4.2.6.1 Single component errors 

The reject component shall be sent in a RELEASE COMPLETE message. 

If the component containing the error was itself sent in a RELEASE COMPLETE message then the contents of the 
component shall be ignored, and no reject component is sent. 
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4.2.6.2 Multiple component errors 

If a single Facility IE contains more than one component then a RELEASE COMPLETE message with the cause 
"Facility rejected" and without any component shall be sent. 



5 Location service support procedures 

5.1 General 

This clause describes the location service support procedures at the radio interface. These procedures are provided by 
the location service support entity defined in 3GPP TS 04.07. The location service support procedures provide the 
means to transfer messages for the location service procedures. These procedures are regarded as the user of the 
location service support. 

5.2 Location service support establishment 

At the beginning of each location service procedure a location service support must be established. 

5.2.1 Location service support establishment at the originating side 

If the entity that uses the location support procedures needs to send a REGISTER message, the location service support 
entity shall first request the establishment of an MM-connection. This MM-connection is established according to 
3GPP TS 04.08 and 04.07. If the network is the initiating side then MM-connection establishment may involve paging 
the LMU. 

The location service support entity shall send the REGISTER message as the first CM-message on the MM-connection. 
The REGISTER message is sent to the corresponding peer entity on the MM-connection and the location service 
support shall be regarded as being established. 

5.2.2 Location service support establishment at the terminating side 

At the terminating side a location service support is regarded as being established when an MM-connection is 
established. According 3GPP TS 04.08 this can be ascertained by the receipt of the first message, with a new 
transaction identifier. For successful establishment of location service support this message shall be a REGISTER 

message. 

If the terminating side needs to reject the establishment of location services support then it may be immediately initiate 
location services support release (see subclause 5.4). 

5.3 Location service support information transfer phase 

After the establishment of the location service support both users may exchange FACILITY messages by use of the 
location service support. 

5.4 Location service support release 

At the end of each location service procedure the established location service support is released, if a permanent 
connection is not used. 

The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its 
corresponding peer entity. 

Both location service support entities release the MM-connection locally. 
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5.5 Recovery procedures 



The location service support does not provide recovery procedures, i.e. the operations are transparent to the location 
service support. 

5.6 Message flow (single operation example) 

This subclause contains examples of message flows for a single transaction consisting of a single operation. These 
examples may not show all possibilities. 

5.6.1 LMU initiated location service transaction 

LMU Network 

REGISTER 
> 

Facility (Invoke = Operation (Location service code, Parameter(s))) 

RELEASE COMPLETE or FACILITY 
< 

Facility (Return result = Operation (Parameter(s))) 

RELEASE COMPLETE or FACILITY 
<------------------- ............................ 

Facility (Return error (Error)) 

RELEASE COMPLETE 

Facility (Reject (Invoke_problem)) 

RELEASE COMPLETE (note) 
< ............. 

RELEASE COMPLETE (note) 
> 

NOTE: To prevent transactions being kept open following exceptional cases, either side of the transaction may 
release it by sending a RELEASE COMPETE message without a Facility IE. 

Figure 3.1 : LIUlU initiated location service transaction 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1 998 12 ETSI TS 1 01 725 V7.3.0 (2001 -06) 

5.6.2 Network initiated location service transaction 

LMU Network 

REGISTER 
< 

Facility (Invoke = Operation (Location service code, Parameter(s))) 

RELEASE COMPLETE or FACILITY (note 1) 
> 

Facility (Return result = Operation (Parameter(s)) 

RELEASE COMPLETE or FACILITY (note 1) 

Facility (Return error (Error)) 

RELEASE COMPLETE (note 1) 
... ......... > 

Facility (Reject (Invoke_problem)) 
RELEASE COMPLETE (note 1, note 2) 

RELEASE COMPLETE (note 2) 

NOTE 1 : If the network initiated operation does not require a result, reject or error to be returned then the LMU 

may release the transaction by sending a RELEASE COMPLETE message without a Facility Information 
Element and release of transaction by LMU is allowed (i.e. Release Forbidden has not been present in 
Register message). If release is not allowed by LMU, the LMU sends the result using Facility message. 

NOTE 2: To prevent transactions being kept open following exceptional cases, either side of the transaction may 
release it by sending a RELEASE COMPETE message without a Facility IE. 

Figure 3.2: Network initiated location service transaction 

5.7 Handling of unknown, unforeseen, and erroneous protocol 
data 

5.7.1 General 

These procedures only apply to messages where the protocol discriminator is set to indicate LCS operations according 
to the rules in 3GPP TS 04.07 and this specification. Messages that do not meet this criteria are treated according to 
other GSM technical specifications. 

This subclause specifies procedures for handling of unknown, unforeseen and erroneous protocol data by the receiving 
entity. The procedures are called "error handling procedures", but they also define a compatibility mechanism for future 
extension of the protocol. 

Most error handling procedures are mandatory in the LMU, but optional in the network. Detailed error handling 
procedures may vary from PLMN to PLMN. 

In this subclause, the following terminology is used: 

An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved" 
in this specification or 3GPP TS 04.08. However, it is not a syntactical error if a type 4 IE specifies a length 
indicator greater than that defined. The component part of the Facility information element is handled by a 
separate mechanism, and errors in the component part are not covered by this subclause. 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1 998 13 ETSI TS 1 01 725 V7.3.0 (2001 -06) 

The following procedures are listed in order of precedence. 

Handling of errors in the contents of the Facility IE is described in subclause 4.2.6, and is outside the scope of this 
subclause. 

5.7.2 Message too short 

When a message is received that is too short to contain a complete message type information element, that message 
shall be ignored. 

5.7.3 Unknown or unforeseen transaction identifier 

The LMU shall ignore messages with the transaction identifier value set to "111". 

If the transaction identifier value is not "111" the following procedures shall apply to the LMU: 

a) If a RELEASE COMPLETE message is received specifying a transaction identifier that is not recognized as 
relating to a LCS transaction that is in progress then the message shall be ignored. 

b) If a FACILITY message is received specifying a transaction identifier that is not recognized as relating to a LCS 
transaction that is in progress then a RELEASE COMPLETE message shall be sent. 

c) If a REGISTER message is received specifying a transaction identifier that is not recognized as relating to a LCS 
transaction that is in progress and with a transaction identifier flag incorrectly set to "1", this message shall be 
ignored. 

The network may follow the same procedures. 

5.7.4 Unl^nown or unforeseen message type 

If the LMU receives a message type not defined for the protocol discriminator or not implemented by the receiver, then 
a RELEASE COMPLETE message shall be sent with cause value #97 "message type non-existent or not implemented". 

If the LMU receives a message type not consistent with the transaction state then a RELEASE COMPLETE message 
shall be sent with cause value #98 "message not compatible with control state". 

The network may follow the same procedures. 

5.7.5 Non-semantical mandatory Information Element Error 

When on receipt of a message: 

an "imperative message part" error; or 

a "missing mandatory IE" error; 
is diagnosed, or when a message containing: 

a syntactically incorrect mandatory IE; or 

an IE unknown in the message, but encoded as "comprehension required" (see 3GPP TS 04.08); or 

an out of sequence IE encoded as "comprehension required"; 
is received, the LMU shall proceed as follows: 

a) If the message is not RELEASE COMPLETE it shall send a RELEASE COMPLETE message with cause "#96 - 
Invalid mandatory information". 

b) If the message is RELEASE COMPLETE, it shall be treated as a normal RELEASE COMPLETE message. 
The network may follow the same procedures. 
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5.7.6 Unknown and Unforeseen lEs in the non-imperative part 

5.7.6.1 lEIs unknown in the message 

The LMU shall ignore all lEs unknown in the message which are not encoded as "comprehension required". The 
network shall take the same approach. 

5.7.6.2 Out of sequence lEs 

The LMU shall ignore all out of sequence lEs in a message which are not encoded as "comprehension required". 
The network may take the same approach. 

5.7.6.3 Repeated lEs 

If an information element with format T, TV or TLV (see 3GPP TS 04.07) is repeated in a message in which repetition 
of the information element is not specified, only the contents of the information element appearing first shall be handled 
and all subsequent repetitions of the information element shall be ignored. When repetition of information elements is 
specified, only the contents of specified repeated information elements shall be handled. If the limit on repetition of 
information elements is exceeded, the contents of information elements appearing first up to the limit of repetitions 
shall be handled and all subsequent repetitions of the information element shall be ignored. 

The network may follow the same procedures. 

5.7.7 Non-imperative message part errors 

This category includes: 

syntactically incorrect optional lEs; 

conditional IE errors. 
Errors in the content of the Facility IE are handled according to subclause 4.2.6. 

5.7.7.1 Syntactically incorrect optional IBs (other than Facility) 

The LMU shall treat all optional lEs that are syntactically incorrect in a message as not present in the message 
The network shall take the same approach. 

5.7.7.2 Conditional IE errors 

When the LMU upon receipt of a message diagnoses a "missing conditional IE" error, or an "unexpected conditional IE 
error", or when it receives a message containing at least one syntactically incorrect conditional IE (other than Facility), 
it shall send a RELEASE COMPLETE message with cause #100 "conditional IE error". 

The network may follow the same procedure. 
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6 Message functional definitions and contents 

6.1 General 

This clause defines the structure of the messages of the layer 3 protocol defined in 3GPP TS 03.71. These messages are 
standard L3 messages as defined in 3GPP TS 04.07. 

Each definition includes: 

a) a brief description of the message; 

b) a table listing the information elements in the order of their appearance in the message. In a sequence of 
consecutive lEs with half octet length, the first IE occupies bits 1 to 4 of octet N, the second bits 5 to 8 of octet 
N, the third bits 1 to 4 of octet N+1 etc.; 

For each IE the table indicates: 

1) the information element identifier, in hexadecimal notation, if the IE has format T, TV or TLV. If the lEI has 
half octet length, it is specified by a notation representing the lEI as a hexadecimal digit followed by a "-" 
(example: B-); 

2) the name of the IE (which gives an idea of the semantics of the element), which is used in this and other 
specifications as a reference to the IE within the message; 

3) the name of the type of the IE (which indicates the coding of the value part of the IE), and a reference to a 
description of the value part of the IE; 

4) the presence requirement indication (M, C or O) for the IE, as defined in 3GPP TS 04.07; 

5) the format of the IE (T, V, TV, LV, TLV) as defined in 3GPP TS 04.07; 

6) the length of the IE (or permissible range of lengths), in octets, in the message, where "?" means that the 
maximum length of the IE is only constrained by the link layer protocol, and in the case of the facility IE by 
possible further considerations specified in 3GPP TS 03.71. This indication is non-normative. 

c) subclauses specifying conditions for lEs with presence requirement C or O in the relevant message. Together 
with other conditions specified in this specification and 3GPP TS 03.71 defines when the IE shall be included or 
not, what non-presence of such lEs means, and (for lEs with presence requirement C) the static conditions for 
presence and/or non-presence of the lEs (see 3GPP TS 04.07). 

6.2 Messages for location services control 

Table 4. 1 summarises the messages for location services control. 

The logical DTAP LCS Information Request and DTAP LCS Information Report messages, that are used in LCS Stage 
2 (3GPP TS 03.71), are transported using REGISTER, FACILITY and RELEASE COMPLETE messages. 

If there exists no LCS transaction between LMU and MSC, REGISTER message is used to deliver the logical message. 
If LCS transaction between LMU and MSC exists, FACILITY message is used to deliver the logical message. 
RELEASE COMPLETE message is used to indicate that LCS transaction is not any more needed, LMU can also use 
this message to transport logical LCS Information Response message. 

Table 4.1 : Messages for location service control 



Messages for location service control 


Reference 


FACILITY 


6.3 


REGISTER 


6.4 


RELEASE COMPLETE 


6.5 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 



16 



ETSI TS 101 725 V7.3.0 (2001-06) 



6.3 Facility 



This message is sent by the Location Measurement Unit (LMU) or the network to request or acknowledge a location 
service. It is used when information is to be conveyed and the transaction already exists, but is not to be released. The 
location service to be invoked, and its associated parameters, are specified in the Facility information element (see table 
4.2). This message contains information transparent to MSC. 

Table 4.2: FACILITY message content 



IE! 


Information element 


Type / Reference 


Presence 


Format 


Length 




Location service 
Protocol discriminator 


Protocol discriminator 
7.2 


M 


V 


1/2 




Transaction identifier 


Transaction identifier 
7.3 


M 


V 


1/2 




Facility 
IVlessage type 


IVlessage type 
7.4 


M 


V 


1 




Facility 


Facility 
7.5 


M 


LV 


2-? 


90 


Release forbidden 


Release forbidden 
7.6 





T 


1 



6.4 Register 

6.4.1 Register (network to LIVIU direction) 

This message is sent by the network to the location measurement unit to assign a new transaction identifier for location 
service control and to request or acknowledge a location service (see table 4.3). This message contains information 
transparent to MSC. 

Table 4.3: REGISTER message content (network to LMU direction) 



lEI 


Information element 


Type / Reference 


Presence 


Format 


Length 




Location service 
Protocol discriminator 


Protocol discriminator 
7.2 


M 


V 


1/2 




Transaction identifier 


Transaction identifier 
7.3 


M 


V 


1/2 




Register 
IVlessage Type 


IVlessage type 
7.4 


M 


V 


1 




Facility 


Facility 
7.5 


M 


LV 


2-? 


90 


Release forbidden 


Release forbidden 
7.6 





T 


1 
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6.4.2 Register (LMU to network direction) 

This message is sent by the location measurement unit to the network to assign a new transaction identifier for location 
service control and to request or acknowledge a location service (see table 4.4). This message contains information 
transparent to MSC. 

Table 4.4: REGISTER message content (LMU to network direction) 



lEI 


Information element 


Type / Reference 


Presence 


Format 


Length 




Location service 
Protocol discriminator 


Protocol discriminator 
7.2 


M 


V 


1/2 




Transaction identifier 


Transaction identifier 
7.3 


M 


V 


1/2 




Register 
Message type 


IVIessage type 
7.4 


M 


V 


1 




Facility 


Facility 
7.5 


M 


LV 


2-? 



6.5 Release complete 



This message is sent by the location measurement unit or the network to release a transaction used for location service 
control. It may also request or acknowledge a location service (see table 4.5). This message contains information 
transparent to MSC. 

Table 4.5: RELEASE COMPLETE message content 



lEI 


Information element 


Type / Reference 


Presence 


Format 


Length 




Location service 
Protocol discriminator 


Protocol discriminator 
7.2 


M 


V 


1/2 




Transaction identifier 


Transaction identifier 
7.3 


M 


V 


1/2 




Release Complete 
Message type 


Message type 
7.4 


M 


V 


1 


10 


Cause 


Cause 

3GPP TS 04.08 





TLV 


4-32 


11 


Facility 


Facility 
7.5 





TLV 


2-? 



6.5.1 Cause 

This information element shall be included when the functional handling of the Cause IE is specified in the service 
description. If the functional handling of the Cause IE is not specified, the receiving entity may ignore the IE. The 
Cause IE used in location services is defined in 3GPP TS 04.08 in Clause 10.5.4. 11 (only applicable Cause values are 
used). 

6.5.2 Facility 

This information element shall be included as required by the service description and the procedures defined in this 
specification and in 3GPP TS 03.71. 
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7 General message format and information elements 

coding between LMU and MSC 

The figures and text in this clause describe message contents. Within each octet, the bit designated "bit 1" is transmitted 
first, followed by bits 2, 3, 4, etc. Similarly, the octet shown at the top of each figure is sent first. 

7.1 Overview 

Within the layer 3 protocol defined in this specification, every message is a standard L3 message as defined in 
3GPP TS 04.07. This means that the message consists of the following parts: 

a) protocol discriminator; 

b) transaction identifier; 

c) message type; 

d) other information elements, as required. 

Unless specified otherwise, a particular information element may be present only once in a given message. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet 
of the field. 

7.2 Protocol discriminator 

The Protocol Discriminator (PD) and its use are defined in 3GPP TS 04.07. This specification defines the protocols 
relating to the PD values: 

110 location services 

7.3 Transaction identifier 

For general rules, format and coding of transaction identifier values, see 3GPP TS 04.08. 



7.4 Message type 



The message type IE and its use are defined in 3GPP TS 04.07. Table 5.1 defines the value part of the message type IE 
used in the location service protocol. 

Table 5.1 : Message types 



8 7 1 6 5 4 3 2 1 1 


Message types 


0X10.... 
1 

0X11.... 
1 
10 


Clearing messages: 

- RELEASE COMPLETE 
Miscellaneous message group: 

- FACILITY 
- REGISTER 


NOTE 1 : Bit 8 is reserved for possible future use as an extension bit, see 3GPP TS 04.07. 
NOTE 2: Bit 7 is reserved for the send sequence number in messages sent from the mobile station. In 
messages sent from the network, bit 7 is coded with a "0", see 3GPP TS 04.07. 
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7.5 Facility information element 



The purpose of the Facility information element is to indicate the invocation and operation of location services, 
identified by the corresponding operation code within the Facility information element. 

The Facility information element is coded as shown in figure 5.1 and clause 8. 

The Facility is a type 4 information element with no upper length limit except that given by the maximum number of 
octets in a L3 message, see 3GPP TS 04.06. 



8 7 1 6 1 5 1 4 3 2 1 




Facility lEI 


octet 1 


Length of Facility contents 


octet 2 


Component(s) (note) 


octet 3 etc. 


NOTE: This component contains Transparent LCS Information. 
Encoding of this component is according to clause 8. 



Figure 5.1 : Facility information element 



7.6 



Release forbidden 



This information element is used only in MSC to LMU messages. The presence of IE indicates that the release of LCS 
transaction is not allowed by LMU. 



8 



General message format and information elements 
coding between LMU and SMLC 



8.1 Transparent LCS Information 



This clause provides the formats and encoding of Transparent LCS Information component in the Facility information 
element. The contents of this component is copied directly from Signal Info from MAP message (see the clause 6.L4). 
Formats and encoding methods make use of and is a subset of ITU-T Recommendation Q.773 (Transaction Capabilities 
formats and Encoding) and T/S 43/BB. The used part of ITU-T Recommendation Q.773 respectively T/S 43/BB is 
almost the same as the Component Portion of TC messages. 

This subclause is further based on: 

- Abstract Syntax Notation One (ASN.l) "Specification of Basic Notation" ITU-T Rec.X.680 (1997) I ISO/IEC 
8824-1:1998 

- ASN.l encoding rules "Specification of Packet Encoding Rules (PER)" ITU-T Rec. X.691 (1997) I ISO/IEC 
8825-2:1998 

and is consistent with these ITU-Trecommendations. BASIC-PER, unaligned variant is used. 

NOTE: Concerning the general rules for encoding (structure of encoding, identifier octets, length octets, etc.) see 
CCITT Recommendations X.208 and ITU-T Recommendation X.691. For these general rules the same 
exceptions apply as stated in 3GPP TS 09.02. Following ASN.l definitions are exactly same than in ITU- 
T Recommendation Q.773. 

NOTE: invokeNotLast component is added to the Component list. This change impacts to the coding of the 
Component type and thus to coding of the LLP messages. 

The Component portion of the TCAP used in this protocol. LLP, is a modification of the TCAP 
Component portion defined in ITU-T Recommendation, Q.773. 
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Component ::= CHOICE { 

invoke [1] IMPLICIT Invoke, 

returnResultLast [2] IMPLICIT ReturnResult , 

returnError [3] IMPLICIT ReturnError, 

reject [4] IMPLICIT Reject, 

returnResultNotLast [7] IMPLICIT ReturnResult, 

invokeNotLast [8] IMPLICIT Invoke } 

— The Components are sequences of data elements. 

Invoke ::= SEQUENCE { 

invokelD InvokeldType, 

linkedlD [0] IMPLICIT InvokeldType OPTIONAL, 

operationCode OPERATION, 

parameter ANY DEFINED BY operationCode OPTIONAL } 

— ANY is filled by the single ASN.l data type following the keyword PARAMETER or the keyword 
ARGUMENT 

— in the type definition of a particular operation. 

ReturnResult ::= SEQUENCE { 

invokelD InvokeldType, 

result SEQUENCE { 

operationCode OPERATION, 

parameter ANY DEFINED BY operationCode 

} OPTIONAL 

} 

— ANY is filled by the single ASN.l data type following the keyword RESULT in the type definition 

— of a particular operation. 

ReturnError ::= SEQUENCE { 

invokelD InvokeldType, 

errorCode ERROR, 

parameter ANY DEFINED BY errorCode OPTIONAL } 

— ANY is filled by the single ASN.l data type following the keyword PARAMETER in the type 
definition 

— of a particular error. 

Reject : := SEQUENCE { 
invokelD CHOICE { 

derivable InvokeldType, 

not-derivable NULL } , 

problem CHOICE { 

generalProblem [0] IMPLICIT GeneralProblem, 

invokeProblem [1] IMPLICIT InvokeProblem, 

returnResultProblem [2] IMPLICIT ReturnResultProblem, 

returnErrorProblem [3] IMPLICIT ReturnErrorProblem} } 

InvokeldType ::= INTEGER (-128.. 127) 



8.1.1 OperationCode 



Each Operation is assigned an Operation Code to identify it. The Operation Codes for the different Operations are 
defined in subclause 9.2. 

8.1.2 ErrorCode 

Each Error is assigned a value (Error Code) to identify it. The Error Codes for the different Errors are defined in 

subclause 7.3. 
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8.1.3 Problem Code 

The Problem Code consists of one of the four elements: General Problem, Invoke Problem, Return Result Problem or 
Return Error Problem. ASN.l definitions are presented below. 

— PROBLEMS 

GeneralProblem : := INTEGER { unrecognizedComponent (0) , 

mistypedComponent (1) , 
badlyStructuredComponent (2 ) } 

InvokeProblem : := INTEGER { duplicatelnvokelD (0) , 

unrecognizedOperation (1) , 
mistypedParameter (2) , 
resourceLimitation (3) , 
initiatingRelease (4) , 
unrecognizedLinkedID (5) , 
linkedResponseUnexpected (6) , 
unexpectedLinkedOperation (7) } 

ReturnResultProblem : := INTEGER { unrecognizedlnvokelD (0) , 

returnResultUnexpected (1) , 
mistypedParameter (2) } 

ReturnErrorProblem ::= INTEGER { unrecognizedlnvokelD (0), 

returnErrorUnexpected (1) , 
unrecognizedError (2) , 
unexpectedError (3) , 
mistypedParameter (4) } 



9 LMU LCS Protocol operation specifications 

9.1 General 

This clause specifies the abstract syntax for the LMU LCS Protocol using the Abstract Syntax Notation One (ASN.l), 
defined in CCITT Recommendation X.680 (1997). 

The encoding rules which are applicable to the defined abstract syntax are the Packet Encoding Rules for Abstract 
Syntax Notation One, defined in ITU-T Recommendation X.691. For each Location Service parameter which has to be 
transferred by a Location Service message, there is a PDU field (an ASN.l NamedType) whose ASN.l identifier has 
the same name as the corresponding parameter, except for the differences required by the ASN. 1 notation (blanks 
between words are removed, the first letter of the first word is lower-case and the first letter of the following words are 
capitalized (e.g. "bearer service" is mapped to "bearerService"). In addition some words may be abbreviated as follows: 

Imu: location measurement unit; 

Ics: location services; 

The ASN.l data type which follows the keywords ARGUMENT "PARAMETER" or "RESULT" (for OPERATION 
and ERROR) is always optional from a syntactic point of view. However, except specific mention, it has to be 
considered as mandatory from a semantic point of view. When in an invoke component, a mandatory element is missing 
in any component or inner data structure, a reject component is returned with the problem code "Mistyped Parameter". 
When an optional element is missing in an invoke component or in an inner data structure while it is required by the 
context, an error component is returned; the associated type of error is "DataMissing". 

In case an element is defined as mandatory in the protocol description (3GPP TS 04.71 including imports from 
3GPP TS 09.02), but is not present according to the service description (stage 1 to stage 3), the ASN.l protocol 
description takes precedence over the diagrams in the 3GPP TS 04. 8x and 04.9x-series of technical specifications. 

When possible operations and errors are imported from 3GPP TS 09.02 thereby making the MSC transparent to most of 
the messages sent to or from the LMU. 

Timer values for operations which require timers are shown as ASN.l comments. 
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Ellipsis Notation shall be used in the same way as described in 3GPP TS 09.02 and shall be supported on the radio 
interface by the LMU and the network for all operations defined in this specification including those imported from 
3GPP TS 09.02. 



9.2 Operation types 



Table 7.1 summarizes the operations defined for LMU LCS Protocol in this specification, and shows which of these 
operations are Radio Interface Timing (RIT) related, Time Of Arrival (TO A) location method related, and general 
LMU procedures related. In this ASN.l module, ASN.1/88 defined in CCITT X.680 recommendations (ASN.l 1997) is 
used. 

Table 7.1 : Relevance of location service operations 



Operation name 


Direction 


Response allowed 


RIT 


TOA 


General LMU 


StartRIT 


SMLC -> LMU 


ReturnResult 
(empty) . 


X 






ReportRIT 


LMU ->SMLC 


No 


X 






StopRIT 


SMLC -> LMU 


ReturnResult 
(empty). 


X 






IndicateRITError 


LMU ->SMLC 


No 


X 






PerformlGA 


SMLC -> LMU 


ReturnResult 




X 




StatusQuery 


SMLC -> LMU 


ReturnResult 






X 


StatusUpdate 


LMU -> SMLC 


ReturnResult 
(empty) 






X 


ResetRequest 


SMLC -> LMU 


ReturnResult 
(empty). 






X 


OMMngrRequest 


SMLC -> LMU 


ReturnResult 






X 


OMAgntRequest 


LMU -> SMLC 


ReturnResult 






X 



This specification defines the following operations (transparent to MSC): 

- StartRIT 

- ReportRIT 

- StopRIT 
IndicateRITError 

- PerformTOA 

- StatusQuery 
StatusUpdate 
ResetRequest 

- OMMngrRequest 

- OMAgntRequest 

— LLP-Operations module defines the operations transparent to MSC 

LLP -Operations 

— { LLP-Operations object identifier } 

DEFINITIONS : := 
BEGIN 



IMPORTS 

OPERATION 
FROM TCAPMes sages { 
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ccitt recommendation q 773 modules (2) messages (1) version2 (2)} 

SystemFailure, 
DataMissing, 
UnexpectedDataValue, 
FacilityNot Supported, 
UnknownSubscriber , 
FROM MAP-Errors { 

ccitt identif ied-organization (4) etsi (0) mobileDomain (0) 
gsm-Network (1) modules (3) map-Errors (10) version! (4) } 

UnDef inedError 
FROM LLP-Errors 

— {} 

StartRITReq, 

StartRITRsp, 

ReportRITArg, 

StopRITReq, 

StopRITRsp, 

ErrorRITArg, 

PerformTOAReq, 

TOAResultRsp, 

StatusReq, 

StatusRsp, 

ResetReq, 

ResetRsp, 

StatusUpdateReq, 

StatusUpdateRsp 
FROM LLP-DataTypes { 

ccitt identif ied-organization (4) etsi (0) mobileDomain (0) 
gsm-Network (1) modules (3) map-LCS-DataTypes (n) version4 (4) } 

OMMngrReq, 
OMMngrRsp, 
OMAgntReq, 
OMAgntRsp, 
NACKCauses 
FROM LLP-OM-Protocol — { LLP-OM-Protocol Object identifier } — 

— OPERATION definitions based on macro notation 



StartRIT::= OPERATION — identifier StartRIT-Measurement 
ARGUMENT 

StartRITReq StartRITReq 
RESULT 

StartRITRsp StartRITRsp 
ERROR { 

SystemFailure, 
DataMissing, 
UnexpectedDataValue, 
ResourcesNot Avail able, 
UnDef inedError 



ReportRIT::= OPERATION — identifier ReportRIT-Measurement 
ARGUMENT 

reportRITArg ReportRITArgR 



StopRIT::= OPERATION 


— identifier StopRIT-Measurement 


ARGUMENT 




StopRITReq 


StopRITReq 


RESULT 




StopRITRsp 


StopRITRsp 



IndicateRITError ::= OPERATION 
ARGUMENT 

errorRITArg ErrorRITArg 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 



24 



ETSI TS 101 725 V7.3.0 (2001-06) 



PerformTOA: := OPERATION 


— identifier Perf ormTOA-Measurment 


ARGUMENT 




perf ormTOAReq 


Perf ormTOAReq 


RESULT 




toaResultRsp 


TOAResultRsp 


ERROR { 




SystemFailure, 




DataMissing, 




UnexpectedDataValue, 




Re s our cesNot Avail able, 




UnDef inedError 
1 





StatusQuery : := OPERATION 




ARGUMENT 




statusReq 


StatusReq 


RESULT 




statusRsp 


StatusRsp 


ERROR { 

} 





ResetRequest : := OPERATION 




ARGUMENT 




resetReq 


ResetReq 


RESULT 




resetRsp 


ResetRsp 


ERROR { 




SystemFailure, 




UnDef inedError 
} 





OMMngrRequest ::= 


OPERATION 


— defined in LLP-OM, 


12.71 


ARGURMENT 








oMMngrReq 


OMMngrReq 






RESULT 








oMMngrRsp 


OMMngrRsp 






ERROR 








NACKCauses 
} 









OMAgntRequest ::= 


OPERATION 


— defined in LLP-OM, 


12.71 


ARGURMENT 








oMAgntReq 


OMAgntReq 






RESULT 








oMAgntRsp 


OMAgntRsp 






ERROR 








NACKCauses 
} 









StatusUpdate ::= OPERATION 


— identifier Status Update 


ARGUMENT 




statusUpdateReq 


StatusUpdateReq 


RESULT 




statusUpdateRsp 


StatusUpdateRsp 


ERROR { 




SystemFailure, 




DataMissing, 




UnexpectedDataValue, 




ResourceNot Avail able. 




UnDef inedError 

} 





END 



9.2.1 Operation types description 

For each operation type this subclause provides a brief prose description. 
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9.2.1 .1 StartRIT (network --> LMU) 

This operation type is invoked by the network to request RIT measurement information from an LMU. 

9.2.1 .2 ReportRIT (LMU -->network) 

This operation type is invoked by an LMU to report to the network RIT measurement information. This operation is 
used to report periodical measurements. 

9.2.1 .3 StopRIT (network --> LMU) 

This operation type is invoked by the network to request an LMU to stop on-going RIT measurements and reporting. 

9.2.1 .4 IndicateRITError (LMU --> network) 

This operation type is invoked by an LMU to indicate error situations. 

9.2.1 .5 PerformTOA (network --> LMU) 

This operation type is invoked by the network to request an LMU to perform TOA location mesurements. The 
measurement results are returned using the return result component of the operation. 

9.2.1 .6 StatusQuery (network --> LMU) 

This operation type is invoked by the network to request status an LMU The status is returned using the return result 
component of the operation. 

9.2.1 .7 StatusUpdate (LMU --> network) 

This operation type is invoked by an LMU to report status of LMU, e.g. after reset or periodically. 

9.2.1 .8 ResetRequest (network --> LMU) 

This operation type is invoked by the network to reset an LMU. 

9.2.1 .9 OMMngrRequest (network --> LMU) 

This operation type is invoked by the network to request a specific O&M activity to LMU as defined in 3GPP TS 12.71. 

9.2.1 .10 OMAgntRequest (LMU -> network) 

This operation type is invoked by the LMU to report an O&M event to Network or asking for reporting O&M 
information from Network as defined in 3GPP TS 12.71. 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 26 ETSI TS 101 725 V7.3.0 (2001-06) 

10.3 Error types 

10.3.1 Error types ASN.1 specification 

The following ASN.l module provides an ASN.l specification of errors. Errors from MAP are imported in the LCS- 
Protocol module in subclause 9.2. In this ASN.l module, ASN.1/88 defined in CCITT X.680 recommendations (ASN.l 
1997) is used. 

LLP-Errors 

— { LLP-Errors object identifier } 

DEFINITIONS : := 

BEGIN 

IMPORTS 

ERROR FROM 

TCAPMes sages FROM { 

ccitt recommendation q 773 modules (2) messages (1) version2 (2) } 

— The MAP errors 

— error types definition 
UnDefinedError : : =ERROR 

END 

1 0.3.2 Error types description 

For each error type this subclause provides a brief prose description. 

10.3.2.4 System Failure 

This error is returned by the LMU or the network, when it cannot perform an operation because of a failure. 

10.3.2.5 DataMissing 

This error is returned by the network or the LMU when an optional parameter is missing in an invoke component or an 
inner data structure, while it is required by the context of the request. 

10.3.2.6 UnexpectedData Value 

This error is returned by the network or the LMU when it receives a parameter with an unexpected value, without type 
violation. 

10.3.2.7 ResourcesNotAvailable 

This error is returned by the network or the LMU if temporarily there are no resources. 

10.3.2.9 UnDefinedError 

This error is returned by the LMU or the network when any other error type is not applicable. 
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10.4 Operations and errors implementation 

For the actual implementation of location services, operations and errors have to be defined by value. The following 
ASN.l module, imports operation types from the ASN.l module described in subclause 9.2 and operation and error 
types from MAP. It defines operations by allocating operations and errors a local value. For the involved operations and 
errors the same local values as in MAP are allocated. In this ASN.l module, ASN.1/88 defined in CCITT X.680 
recommendations (ASN.l 1997) is used. 



LLP-Protocol 

— { LLP-Protocol object identifier } 

DEFINITIONS : := 



IMPORTS 



SystemFailure, 

DataMissing, 
UnexpectedDataValue, 
FacilityNot Supported, 
UnknownSubscriber , 
FROM MAP-Errors { 

ccitt identif ied-organization (4) etsi 
gsm-Network (1) modules (3) map-Errors 



(0) mobileDomain (0) 
(10) version4 (4) } 



UnDef InedError 
FROM LLP-Errors 

— { LLP-Errors object identifier } 

StartRIT, 

ReportRIT, 

StopRIT, 
IndicateRITError, 

PerformTOA, 

StatusQuery, 

ResetRequest, 

OMRequest, 

OMReport, 

StatusUpdate 
FROM -LLP-Operations 

— { LLP-Operations object identifier } 

— allocate local values for errors 

SystemFailure SystemFailure ::= localValue 10 

dataMissing DataMissing ::= localValue 11 

UnexpectedDataValue UnexpectedDataValue ::= localValue 12 

f acilityNotSupported FacilityNotSupported ::= localValue 13 

unknownSubscriber UnknownSubscriber ::= localValue 14 

unDef inedError UnDef InedError ::= localValue 50 



StartRIT StartRIT ::= localValue 10 

reportRIT ReportRIT : := localValue 11 

StopRIT StopRIT ::= localValue 12 

IndicateRITError IndicateRITError : := localValue 13 

performTOA PerformTOA : := localValue 20 

StatusQuery statusQuery ::= localValue 30 



resetRequest 
omMngr Request 
omAgnt Request 
StatusUpdate 



ResetRequest : 
OMMngrRequest 
OMAgntRequest 
StatusUpdate : 



localValue 31 
= LocalValue 32 
= LocalValue 33 

LocalValue 34 



END 
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1 1 LMU LCS Protocol (LLP) messages 

11.1 Messages, data types and identifiers 

11.1.1 General 

This clause defines the External Signal Info IE, that contains Signal Info string. Signal Info string contains the MLC- 
LMU messages defined by ASN.l and coded by PER (X.691). In this ASN.l module, ASN.1/94 defined in ITU-T 
X.680 recommendations (ASN.l 1997) is used. 

11.1.2 ASN.l datatypes 

LLP-DataTypes 

— { LLP-DataTypes object identifier } 

DEFINITIONS AUTOMATIC TAGS ::= 

BEGIN 

IMPORTS 

ExtensionContainer 

FROM MAP-ExtensionDataTypes { 

ccitt identif ied-organization (4) etsi (0) mobileDomain (0) 

gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version4 (4)} 



StartRITReq 



SEQUENCE { 



r it-Measurement Type 
r it-Rep ortingType 
r it-Environment 
rit-NeigborNumber 
rit-NeighborXype 
rit-CIMethod 
rit-BTSInfo 
extensionContainer 



RIT-MeasurementType, 

RIT-ReportingType, 

RIT -Environment, 

RIT-NeighborNumber, 
RIT-NeighborType, 

CIMethod, 

RIT-BTSInfo OPTIONAL, 

ExtensionContainer OPTIONAL, 



StartRITRsp ::= SEQUENCE { 
extensionContainer 



ExtensionContainer OPTIONAL, 



StopRITReq ::= SEQUENCE { 

extensionContainer ExtensionContainer OPTIONAL, 



StopRITRsp ::= SEQUENCE { 

extensionContainer ExtensionContainer OPTIONAL, 

} 

ReportRITArg ::= SEQUENCE { 

rit-ReferencelDInfo RIT-ReferencelDInf o, 

rit-ResponseInf o SeqOfRIT-ResponseInf o, 

extensionContainer ExtensionContainer OPTIONAL, 



StatusReq ::= SEQUENCE { 
extensionContainer 



ExtensionContainer OPTIONAL, 
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StatusRsp ::= SEQUENCE { 
statusTime 
rit-Status 
toa-Status 
omStatus 
extensionContainer 



StatusTime, 

RIT-Status, 

TOA-Status, 

OMStatus, 

ExtensionContainer 



OPTIONAL, 



} 



ErrorRITArg ::= SEQUENCE { 
r it-Err or Type 
rit-ErrorReason 
extensionContainer 



RIT-ErrorType, 
RIT-Err or Reason, 
ExtensionContainer OPTIONAL, 



} 

PerformTOA ::= SEQUENCE { 

toa-MeasurementDeviceInf o TOA-MeasurementDeviceInf o, 

toa-ChannelDescr TOA-ChannelDescr, 

toa-SignalDescr TOA-SignalDescr, 

toa-TimingDescr TOA-TimingDescr, 

toa-MeasurementOpt TOA-MeasurementOpt OPTIONAL, 

extensionContainer ExtensionContainer OPTIONAL, 



TOAResultRsp ::= SEQUENCE { 

toa-TimingReferenceInf o TOA-TimingReferenceInf o, 
toa-Measurements TOA-MeasurementInf o, 

extensionContainer ExtensionContainer OPTIONAL, 



} 



StatusUpdateReq ::= SEQUENCE { 



statusReason 

StatusTime 

ritStatus 

toaStatus 

omStatus 

extensionContainer 



StatusReason, 
StatusTime, 
RIT-Status, 
TOA-Status, 

OMStatus, 
ExtensionContainer OPTIONAL, 



StatusUpdateRsp ::= SEQUENCE { 

extensionContainer ExtensionContainer OPTIONAL, 



ResetReq ::= SEQUENCE { 

extensionContainer ExtensionContainer OPTIONAL, 



ResetRsp ::= SEQUENCE { 

extensionContainer ExtensionContainer OPTIONAL, 



— DATA TYPES DEFINITION 

— RIT measurement Type information 
RIT-MeasurementType : := INTEGER { 

atdMeasure (0) , 
atdOrOtdMeasure (1), 
rtdMeasure (2) 
} (0..7) 

— RIT Reporting Type information 
RIT-ReportingType ::= SEQUENCE { 

rit-ReportingPeriodlnfo RIT-ReportingPeriodInf o OPTIONAL, 

rit-ChangeLimit INTEGER (1..255) OPTIONAL, 

rit-DeviationLimit INTEGER (1..255) OPTIONAL, 

rit-MonitorPeriod INTEGER (1..64) OPTIONAL 
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RIT-ReportingPeriodlnfo ::= SEQUENCE { 

rit-ReportingPeriodFormat ENUMERATED { 

tensOf Seconds (0) , 
tensOfMinutes (1) 
rit-ReportingPeriod INTEGER (1..120) 
} 



— RIT Environment Information 
RIT-Environment : := INTEGER { 
heavyMultiPathAndNLOS (0), 

— bad urban or urban heavy multipath and NLOS conditions 
lightMultiPathAndLOS (1), 

— suburban or rural ligth multipath and LOS conditions 
mixedEnvironement (2) 

— not defined or mixed environment 



} (0..7) 



RIT-NeighborNumber 



INTEGER (0. .15) 



RIT-NeighborType ::= INTEGER { 

listedNeighbors (0) , 

listedAndSystemlnf o2or5 (1) , 

systemInfoType2or5 (2), 

allNeighbors (3) 
} (0..7) 

CIMethod ::= INTEGER { 

notCi (0) , — report ci and carrier instead of CI 

ci (1) — report CI if possible 
1 {0..3) 



— element contains information of base stations 

— to be measured 

RIT-BTSInfo ::= SEQUENCE (SIZE (1 . . 31) ) OF RIT-BTSList 



list of btss 



RIT-BTSList ::= SEQUENCE { 
rit-ListCi CI, 
rit-TimeSlot Scheme 
rit-ListBSIC 
rit-ListBCCHCarrier 

} 



Times lot Scheme, 

BSIC, 

BCCHCarrier 



CI 



INTEGER (0. . 65535) 



TimeSlotScheme ::= INTEGER { 
schemeUnknown (0) , 

equalLength (1), — time slots are equal length 
variousLength (2) — the first time slot is 157b 

} (0..7) 

BSIC ::= INTEGER (0..63) 
BCCHCarrier ::= INTEGER (0..1023) 



RIT-ReferencelDInfo ::= SEQUENCE { 

rit-ReferenceLAC LAC, 

rit-Ref erenceCI CI, 



— defined earlier 
defined earlier 



rit-Ref erenceFrameNbr 



FrameNumber , 



defined earlier 



— If rit-ATRef erence is absent then there is not RIT AT refernce value. 
rit-ATReference RIT-ATRef erence OPTIONAL, 



rit-Ref erence Time Slot 
rit-Ref erenceRXLevel 
rit-ATDRTDQualityRes 
rit-ATDRTDChangeQualityRes 



TimeSlot, 
RXLevel, 
INTEGER (0. .3) , 
INTEGER (0. .3) 



-- defined earlier 

-- defined earlier 

-- defines the resolution for ATDRTD values 

-- defines the resolution for ATDRTD change values 



RIT-NoATRef erence 



NULL 



RIT-ATReference ::= SEQUENCE { 

rit-CommonClock CommonClock, 

rit-Ref erence AT Value Ref erenceATValue, 

— This Quality information defines the quality of AT value 
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} 



— Resolution defines the resolution of Quality field as follows, 

— 0= 0.005 us, 1= 0.01 us, 2= 0.05 us 
rit-RefATQuality SEQUENCE { 

resolution INTEGER (0..3), 
atQuality INTEGER (0..63) }, 
rit-ReferenceATChange INTEGER (-1000 .. 1000), 

— This Quality information defines the quality of ATChange value 

— Resolution defines the resolution of Quality field as follows, 

— 0= 0.00005 ppm, 1= 0.0001 ppm, 2= 0.0005 
rit-RefATChangeQuality SEQUENCE { 

resolution INTEGER (0..3), 
atChangeQuality INTEGER (0..63) } 



— Editor's note: ReferenceATValue was divided in two parts because 15 999 999 999 requires 34 bits. 

— In order to handle 34-bits values, LMU should support 64-bits calculation, which can cause 
problems . 

— This solution can be handled with 32-bits and in addition it gives better resolution. 
ReferenceATValue ::= SEQUENCE { 

seconds INTEGER (0..59), 
nsecods INTEGER (0 .. 999999999) 
} 



SeqOfRIT-Responselnfo 



SEQUENCE (SIZE (1..15)) OF RIT-ResponseInf o 



— Measured RTD values from one neighbor 
RIT-Responselnfo ::= SEQUENCE { 



} 



rit-NeighborCelllDInfo 



RIT-CelllDInfo, 



rit-NeighborTimeSlot TimeSlot, 
rit-NeighborRxLevel RXLevel, 

rit-NeighborFrameNumber FrameNumber OPTIONAL, 

rit-NeighborATDRTD INTEGER (0.. 923200), 

rit-NeighborATDRTDQuality INTEGER (0..63), 

rit-NeighborATDRTDChange INTEGER (-2000 .. 2000) , 



RIT-CelllDInfo ::= CHOICE { 
rit-NeighborCI 
rit-NeighborBTS 



CI, 
RIT-NeighborBTS 



RIT-NeighborBTS ::= SEQUENCE { 

rit-NeighborBSIC BSIC, 

rit-NeighborBCCHCarrier BCCHCarrier 
} 

FrameNumber ::= INTEGER (0.. 2715647) 
LAC ::= INTEGER (0.. 65535) 

CommonClock ::= INTEGER { 

gpsClock (0), 

glonass (1) 
} (0..7) 

TimeSlot ::= INTEGER (0..7) 

RXLevel ::= INTEGER (0..63) — range -150 to -24 with 2dBm steps 

— STATUS ELEMENTS 



StatusReason : : 
powerUp (0) , 
unsucSWReset (1), 
sucSWReset (2), 
unknownError (3), 

unrelTBError ( 4 ) , 

periodicReport (5) , 



ENUMERATED { 



— no knowledge about previous states 

— unsuccessful recovery 

— successful recovery 

— unknown self diagnosis error 

— unreliable timebase error 

— periodic status report 



StatusTime ::= SEQUENCE { 

referenceLAC LAC, — defined earlier 

referenced CI, — defined earlier 

ref erenceFrameNumber FrameNumber — defined earlier 
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RIT-Status ::= INTEGER (0..63) — defines the number of RIT-Jobs 
TOA-Status ::= INTEGER (0..63) — defines the number of TOA-Jobs 

OMStatus ::= INTEGER (0..63) — defines the number of OM-Jobs 

— ERROR RIT ELEMENTS 

RIT-ErrorType ::= INTEGER { 

permament (0) , 

temporary (1) 
} {0..3) 

RIT-ErrorReason : := INTEGER { 

noNeighbors (0) , 
noReferenceClock (1), 
notSupportedType (2), 
undef inedError (3) 
} (0..15) 

— TOA DEFINITIONS 

— MEASUREMENTDEVICE INFORMATION 

TOA-MeasurementDevicelnfo ::= SEQUENCE (SIZE (1.. 6)) OF TOA-LMUMeasurementDevice 

— list of measurement devices 

TOA-LMUMeasurementDevice ::= INTEGER (0..5) 

— CHANNEL DESCRIPTION 
TOA-ChannelDescr ::= SEQUENCE { 

toa-FrequencyListType TOA-FrequencyListType, 
toa-hopping TOA-Hopping OPTIONAL, 

toa-channelType TOA-ChannelType, 
toa-numberOf Bursts TOA-NumberOf Burst 
} 

TOA-FrequencyListType ::= CHOICE { 

frequency Li St Only FrequencyListOnly, 

f requencyListAndlndex FrequencyListAndlndex, 

f requencylndexOnly Frequency IndexOnly 
} 

FrequencyListOnly ::= SEQUENCE (SIZE (1 . . 64 ) ) OF TOA-ARFCNumber 

— list of channels 

FrequencyListAndlndex : := SEQUENCE { 

toa-arfcnList TOA-ARFCList , 

— list of channels 

f requencylndex Frequencylndex 

} 

TOA-ARFCList ::= SEQUENCE (SIZE (1 . . 64 ) ) OF TOA-ARFCNumber 

Frequency IndexOnly : := SEQUENCE { 

frequencylndex Frequencylndex 



Frequencylndex ::= INTEGER (0..31) 



TOA-ARFCNumber : := BCCHCarrier — defined earlier 



TOA-Hopping ::= SEQUENCE { 

toa-maio MAIO, 

toa-hsn HSN, 

toa-Msf rameNumber ModuloFrameNumber 



MAIO ::= INTEGER (0..63) — Mobile Allocation Index Offset 
HSN ::= INTEGER (0..63) — Hopping Sequence Number 
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ModuloFrameNumber ::= INTEGER (0.. 84863) 

TOA-ChannelType ::= INTEGER { 
tchf (0) , 



tchhscnO (1), 
tchhscnl (2) 
} {0..7) 

TOA-NumberOfBurst ::= INTEGER (0..7) 



— SIGNAL DESCRIPTION 
TOA-SignalDescr ::= SEQUENCE { 

toa-BurstType TOA-BurstType 



TOA-BurstType ::= CHOICE { 

toa-AccessBurst TOA-AccessBurst, — access burst 

toa-TSC TSC — normal burst 



TOA-AccessBurst ::= SEQUENCE { 

toa-HOReference HOReference, 

toa-BSIC BSIC — defined earlier 

} 

HOReference ::= INTEGER (0..255) 
TSC : := INTEGER (0. .7) 

— TIMING DESCRIPTION 

TOA-TimingDescr ::= SEQUENCE { 

toa-TimeReference TOA-TimeReference, 

toa-timeUncertainty TimeUncertainty 
} 

TOA-TimeReference ::= CHOICE { 

toa-gpsTime TOA-GPSTime, 

toa-gsmSt art Time TOA-GSMSt art Time 

} 

TOA-GPSTime ::= SEQUENCE { 

toa-GPSStartTime GPSStartTime, 

toa-GPSSV GPSSV 

} 

GPSStartTime ::= INTEGER (0 .. 14 999999) — unit is microseconds 

GPSSV ::= INTEGER (0..31) 

TOA-GSMStartTime ::= SEQUENCE { 

toa-arfcn BCCHCarrier, — defined earlier 

toa-bsic BSIC, — defined earlier 

toa-GSMStartTime GSMTime 



GSMTime ::= SEQUENCE { 

toa-GSMTimeframeNumber GSMTimeFrameNumber , 

toa-timeSlot TimeSlot, 

toa-bitNumber BitNumber 



GSMTimeFrameNumber ::= INTEGER (0.. 42323) 
BitNumber ::= INTEGER (0..156) 
TimeUncertainty ::= INTEGER (0..15) 

— MEASUREMENT OPTIONS 
TOA-MeasurementOpt ::= SEQUENCE { 
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toa-LMUMethod TOA-Method, 

toa-Environment TOA-Environment , 

toa-MeasurementType TOA-MeasurementType 
} 

TOA-Method ::= INTEGER (0..7) 

TOA-Environment ::= INTEGER { 

heavyMpathAndNLOS (0), 

lightMpathAndLOS (1), 

mixed (2) 
} (0..7) 

TOA-MeasurementType : := INTEGER { 

reportTOA-only (0) , 

report AOA-only (1), 

reportTOAandAOA (2) 
} (0..3) 



— TIMING INFO 

TOA-TimingReferencelnfo : := CHOICE { 

toa-GPSTimelnfo NULL, 

toa-GSMTimelnfo TOA-GSMTimeInf o 
} 

TOA-GSMTimelnfo ::= SEQUENCE { 

toa-bcch BCCHCarrier, — defined earlier 

toa-bsic BSIC — defined earlier 



— THE ACTUAL TOA MEASUREMENTS 

TOA-Measurementlnfo ::= SEQUENCE (SIZE (1.. 6)) OF TOA-Measurements 
— list of measurementDevices 

TOA-Measurements ::= SEQUENCE { 

toa-Measurement Device ID MeasurementDevicelD, 
toa-AddMeasurementInf o TOA-AddMeasurementInf o, 
toa-measuredPeakList TOA-MeasuredPeakList 



— MEASUREMENT DEVICE ID IE 
MeasurementDevicelD ::= INTEGER (0..5) 

— MEASUREMENT INFO IE IN RESULT MESSAGE 

TOA-AddMeasurementlnfo ::= SEQUENCE { 

toa-Method TOA-Method, — defined earlier 

toa-Diversity TOA-Diversity, 

toa-NumberOfBurst TOA-NumberOf Burst , — defined earlier 

toa-AOA TOA-AOA OPTIONAL, 

toa-AOAUncertainty TOA-AOAUncertainty OPTIONAL 



TOA-Diversity ::= INTEGER { 

noDiversity (0), 

diversity (1) 
} {0..3) 



TOA-AOA ::= INTEGER (0..3599) 
TOA-AOAUncertainty ::= INTEGER (0..31) 

— PEAKS LIST OF MEASURED TOAs 

TOA-MeasuredPeakList ::= SEQUENCE (SIZE (0.. 4)) OF TOA-MeasuredPeaks 
— list of peaks 
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— MEASURED TOA IE 

TOA-MeasuredPeaks ::= SEQUENCE { 

toa-MeasuredTOA MeasuredTOA, 

toa-Qualitylnfo TOA-QualityInf o 

} 

MeasuredTOA ::= INTEGER (-131072 .. 131071) 

— the absolute TOA value 

TOA-Qualitylnfo ::= SEQUENCE { 

toa-Uncertainty TOA-Uncertainty OPTIONAL, 

snrEstimate SNREstimate OPTIONAL, 

toaSignalStrength TOASignalStrength OPTIONAL 

} 

TOA-Uncertainty ::= INTEGER (0..63) 

— the uncertainty of the TOA estimate 

SNREstimate ::= INTEGER (-30.. 33) 

— the estimated value for Signal Noise Radio 

TOASignalStrength ::= INTEGER (0..63) 

— range -150 to -24 with 2dBm steps 



The definition below will be imported from MAP specification. 

MAP-ExtensionDataTypes { 

ccitt identif ied-organization (4) etsi (0) mobileDomain (0) 
gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version4 (4) 

DEFINITIONS 

IMPLICIT TAGS 



BEGIN 

EXPORTS 

PrivateExtension, 
ExtensionContainer; 



MAP-EXTENSION ::= CLASS { 
SExtensionType OPTIONAL, 

Sextensionid OBJECT IDENTIFIER } 

— The length of the Object Identifier shall not exceed 16 octets and the 

— number of components of the Object Identifier shall not exceed 16 



— data types 

— ExtensionContainer : := SEQUENCE { 

privateExtensionList [ 0] PrivateExtensionList OPTIONAL, 
pcs-Extensions [ 1 ] PCS-Extensions OPTIONAL, 



PrivateExtensionList ::= SEQUENCE SIZE (1 . .maxNumOf PrivateExtensions) OF 
PrivateExtension 

PrivateExtension ::= SEQUENCE { 
extid MAP-EXTENSION. Sextensionid 
( {ExtensionSet } ) , 

extType MAP-EXTENSION. SExtensionType 

({ExtensionSet} {@extld}) OPTIONAL} 

maxNumOfPrivateExtensions INTEGER : := 10 

ExtensionSet MAP-EXTENSION ::= 
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— — ExtensionSet is the set of all defined private extensions 

— } 

— Unsupported private extensions shall be discarded if received. 

— PCS-Extensions ::= SEQUENCE { 

— END 



11.1.3 Identifiers definition 

In the informative annexes the contents of the identifiers used in operation and error types description are further 
discussed. 
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Annex A (informative): 
RIT messages 

A.1 Introduction 

This annex describes the contents of Radio Interface Timing (RIT) related messages. 

A.2 IVIessages 

The messages below are considered to be transported between the SMLC and the LMU. 

A.2.1 RIT IVIeasurement Request IVIessage 

The RIT Measurement Request is a message from the SMLC to the LMU. As a response to it the LMU performs Real 
Time Difference (RTD) or Absolute Time Difference (ATD) measurements. It contains the following information 
elements. 

Table A.1 : RIT Measurement Request message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type A.2.L1 .1 


M 


Measurement Instructions 


Measurement 
Instructions A.2.1. L2 


M 


BTS List 


BTS List A.2.1. 1.3 


C 



A.2.1 .1 RIT Measurement Request Message Information Elements 
A.2. 1 . 1 . 1 Message Type I E 

This IE contains the type of the message. This IE is mandatory. 

A.2.1 .1 .2 Measurement Instructions IE 

The purpose of the Measurement Instructions IE is to inform the LMU about the measurement type (RTD/ ATD), 
measurement result reporting rate, and tell which BTSs should be measured. This IE is mandatory, and it contains the 
following fields: 

Measurement Type 

This field indicates whether AT of reference BTS is required. 

X)': AT of reference BTS should be reported. If AT of reference BTS can not be measured, no ATD/RTD 
measurements are reported, but RIT Error IE is sent instead. 

'1 ': AT of reference BTS should be reported . If AT of reference BTS can not be measured, ATD/RTD 
measurements are reported anyhow. 

2': ATD/RTD measurements timestamped with frame number of the reference BTS should be performed. 

Reporting Period Format 

This field describes the units of the Reporting Period field. This field is optional. If this field is included, RIT 
Measurement Responses shall be send with the period indicated in this and Reporting Period fields. 

D': Reporting Period is told in tens of seconds. 
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'1 ': Reporting Period is in tens of minutes. 

Reporting Period 

This field describes the value for the reporting period, i.e. the required time period between the RIT 
Measurement Response messages. Its units and multiplication factor are defined in the Reporting Period Format 
field. This field is conditional and included only if the Reporting Period Format is included. 

Range: 0-120 

Change Limit 

This field indicates the limit for the change of AT or ATD /RTD values in units of 0.02 micro-seconds. If any 
AT or ATD/RTD value has changed more than the value in this field since the last RIT Measurement Response, 
a new RIT Measurement Response message is sent. This field is optional. If this field is included, RIT 
Measurement Responses shall be send when some RIT value has changed more than this limit. 

Range: 1-255 

Deviation Limit 

This field indicates the limit for the deviation of the AT or ATD/RTD values. If any time the predicted AT or 
ATD/RTD value (based on reported AT or ATD/RTD values and changes in the last RIT Measurement 
Response) has deviated more than the value in this field compared to the current measurement result, a new RIT 
Measurement Response message is sent. This field is optional. If this field is included, RIT Measurement 
Responses shall be send when the first deviation of some RIT value is more than this limit. The values are in 
units of 0.02 micro-seconds. 

Range: 1-255 

NOTE: Predicted AT or ATD/RTD value means the value that is calculated (extrapolated) based on AT or 
ATD/RTD value and AT or ATD/RTD Change value in last RIT Measurement Response message. 

Monitor Period 

This field indicates the requested time period for monitoring the time derivative of AT or ATD/RTD values, i.e. 
on how long monitor period the reported AT or ATD/RTD change is based. The value is in tens of seconds. This 
field is optional 

Range: 1-6 

Environment Characterization 

Environment Characterization field gives a LMU information about expected multipath and NLOS in the area. 

X)': possibly heavy multipath and NLOS conditions (e.g. bad urban or urban) 

1': no or light multipath and usually LOS conditions (e.g. suburban or rural) 

2': not defined or mixed environment 

3': reserved 

'4': reserved (i.e. several values should be reserved) 

Neighbor Number 

This field indicates the maximum number of neighbor BTSs that the LMU should try to report. 

Range: 0-15 

Neighbor Type 

This field indicates which neighbor BTSs are used for RIT measurements. If the value of the Neighbor Number 
field is lower than the total number of BTSs in the required list, then the BTS are selected in the order of the list. 

X)':Neighbor BTSs listed in the BTS List IE are used for RIT measurements in the order of the list. 

1': If possible, neighbor BTSs listed in the BTS List IE are used, otherwise neighbors received in SYSTEM 
INFORMATION 2 or 5 message are used in the order of received signal strength. 

'2': Neighbor BTSs indicated in SYSTEM INFORMATION TYPE 2 or 5 are used for RIT measurements 
(i.e. this is normal operation) in the order of received signal strength. 
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3': All neighbor BTSs that can be received (i.e. reported BTSs are not limited to BTSs listed in SYSTEM 
INFORMATION TYPE 2 or 5 or BTS List IE). Support of this option in LMU is optional. 

CellldMethod 

CellldMethod field indicates whether CI or BSIC and BCCH carrier is used to identify neighbor BTSs in RIT 
Measurement Responses. 

X)' = BSIC and BCCH carrier are used to identify the cell, even if CI is available. 

'1 ' = CI is used to identify the neighbor cell, if it is available, otherwise BSIC and BCCH carrier are used. 

A.2.1.1.3 BTS List IE 

This information element indicates neighbor BTSs that are used for RIT measurements. This IE is conditional. If 
Neighbor Type field in the Measurement Instructions IE is X)' or 1 ' this field must be included. The first BTS on the list 
is the reference BTS that should be used as reference when reporting the RTD or AT values. If this reference BTS is not 
available, the LMU can select the used reference BTS based on signal strength. 

This IE contains the following fields. 

Number of BTSs 

This field indicates, how many BTSs are included in this IE. 

Range: 1 to 3L 

The following fields are repeated the number of times included in Number of BTSs field. 

CI 

This field indicates the Cell Identity of the particular BTS. The purpose of the Cell Identity value is to identify a 
BTS within a location area. 

Range: - 65535 

NOTE: Here is assumed that when LMU starts to make measurements, it firsts goes to the requested frequencies, 
and starts to decode BSICs and CIs from those specific frequencies. Because of this procedure the risk 
that there would be two BTSs with same CIs and same Channel numbers is minimal (i.e. there is no need 
to transmit LAC). 

Time Slot Scheme 

The Time Slot Scheme field indicates what kind of transmission scheme the particular BTS is using. If the LMU 
measures signals from BTSs from other time slots than or 4, and it is informed about the burst length schemes 
used by BTSs, then it can compensate for the possible error. (This is necessary if the LMU averages bursts from 
different time slots, and the BTS uses varying lengths of bursts.) 

X)' = the burst scheme is unknown (The time slot should remain the same) 

1' = all time slots are 156.25 bits long 

2' = time slots and 4 are 157 bits long and other time slots are 156 bits long 

BSIC 

This field indicates the BSIC (Base Station Identity Code) of the particular BTS. 

Range: 0-63 

BCCH Carrier 

This field indicates the absolute RF channel number of the particular BTS. 

Range: 0-1023 
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A.2.2 RIT Measurement Response Message 

The RIT Measurement Response is a message from the LMU to the SMLC. It is the response to the RIT Measurement 
Request. It contains the following information elements. 

Table A.2: RIT Measurement Response message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type A.2. 2. 1.1 


M 


RIT Measurement 


RIT Measurement 
A.2.2.1.2 


M 



A.2.2. 1 RIT Measurement Response Message Information Elements 
A.2.2.1.1 Message type IE 

This IE contains the type of the message. This IE is mandatory. 

A.2.2.1 .2 RIT Measurement IE 

This IE includes the required RIT measurements. The length of this IE depends on the number of measured neighbor 
BTSs. This IE is mandatory. 

Reference LAC 

This field indicates the Location Area Code of the reference BTS. The purpose of the Location Area Code is to 
identify a location area. 

Range: - 65535 

Reference CI 

This field indicates the Cell Identity value of the reference BTS. The purpose of the Cell Identity value is to 
identify a cell within a location area. 

Range: - 65535 

Reference Frame Number 

This field indicates the frame number of the last measured burst from the reference BTS. 

Range: 0-2715647 

Response Type 

This field indicates whether AT of reference BTS is reported or not. 

X)': AT of reference BTS is not reported 
'r:AT of reference BTS is reported 

Common Clock 

This field indicates the type of the common reference clock for AT measurement. This field is included only if 
the Response Type field is 1 '. 

X)': GPS clock is used. 

1': Reserved for future use (e.g. Synchronized atomic clocks, or GLONASS) 

Reference AT 

This field indicates the measured AT value for the serving BTS. It is the starting moment of a time slot. It is 
counted in two parts: seconds after last minute change, and nanoseconds after last second change. This field is 
included only if the Response Type field is '1 '. 

Range: 

seconds: 0-59 
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nanoseconds: 0-999,999,999 



Reference AT Quality Resolution 

Reference AT Quality Resolution field includes the resolution used in Reference AT Quality field. Encoding on 2 
bits as follows 



X)0' 


0.005 micro seconds 


X)l' 


0.01 micro seconds 


10' 


0.05 micro seconds 


11' 


Reserved. 



This field is included only if the Response Type field is '1 '. 

Reference AT Quality 

Reference AT Quality field includes the quality of reported RIT measurement. This Reference AT Quality field can 
be e.g. used to evaluate the reliability of AT measurements in the SMLC. Reference AT quality is defined as 

Reference AT Quality = \E^X - ju) J= Std of reported AT value, 

where X is the reported Reference AT value and fl = E\x\ is its expectation value. The reporting resolution of 
Reference AT Quality is defined by Reference AT Quality resolution field. 

Range: to 63 

Value 63 means that Reference AT Quality is greater than or equal to R*63, where R is the resolution defined in 
Reference AT Quality Resolution field. 

This field is included only if the Response Type field is '1 '. 

Reference AT Change 

This field indicates the first time derivative of the AT value for the reference BTS. This value is based on 
measurements made during Monitor Period, if the monitoring period is provided. Otherwise it is the best 
estimate of AT Change value at the time of last AT measurement. This field is conditional and included if 
Response Type field is '1' . The range is -0.05 . . . 0.05 ppm and resolution is 0,00005 ppm. 

Range: -1000 ... 1000 

Reference AT Change Quality Resolution 

Reference AT Change Quality Resolution field includes the resolution used in Reference AT Change Quality field. 
Encoding on 2 bits as follows 

'00' 0.00005 ppm 

'01' 0.0001 ppm 

'10' 0.0005 ppm 

'ir Reserved. 

This field is conditional and included if the Response Type field is '1'. 



Reference AT Change Quality 

Reference AT Change Quality field includes the quality of reported Reference AT Change. This Reference AT 
Change Quality field can be e.g. used to evaluate the reliability of RIT measurements in the SMLC. Reference 
AT Change Quality is defined as 
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Reference AT Change Quality = ^J E^X — ju) J= Std of reported AT Change value 

where X is the reported Reference AT Change and fj. = E\x\ is its expectation value. The reporting resolution 
of Reference AT Change Quality is defined by Reference AT Change Quality Resolution field. 

Range: to 63 

This field is conditional and included if the Response Type field is '1 '. 

Reference Time Slot 

Reference Time Slot indicates the time slot relative to which the LMU reports the reference BTS measurements. 
This field is mandatory. 

Range: to 7 

NOTE: If the LMU does not know timeslot scheme, the LMU reports the used timeslot. The LMU can only report 
results based on one time slot (N) or two time slots (N and N+4). If the LMU knows timeslot scheme, the 
LMU can make measurements from several timeslots and reports that the used timeslot is zero (and 
makes correction). 

Reference RX Level 

RX Level field includes the received signal strength of the reference BTS. 

The RX Level is expressed in 2 dBm steps within the range -150 .. -24 dBm. 

Range: .. 63 

ATD/RTD Quality Resolution 

ATD/RTD Quality Resolution field includes the resolution used in ATD/RTD Quality field. Encoding on 2 bits as 
follows 

'00' 0.005 micro seconds 

'Or 0.01 micro seconds 

'10' 0.05 micro seconds 

'ir Reserved. 

This field is mandatory. 



ATD/RTD Change Quality Resolution 

ATD/RTD Change Quality Resolution field includes the resolution used in ATD/RTD Change Quality field. Encoding 
on 2 bits as follows 

'00' 0.00005 ppm 

'01' 0.0001 ppm 

'10' 0.0005 ppm 

'11 ' Reserved. 

This field is mandatory. 

Number of Measured Neighbors 

This field indicates the number of different neighbor BTSs. 

NOTE: If the LMU can not measure any neighbor BTSs, then this value is set to '0'. 
Range: 0-15 
The following fields are repeated the number of times included in Number of Measured Neighbors field. 
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CellldType 

This field indicates is the identity method of the cell. 

D' = Cell identity is told using BSIC and BCCH carrier. 
1 ' = Cell identity is told using CI. 

Neighbor CI 

This field indicates the Cell Identity of the particular neighbor cell. The purpose of the Cell Identity value is to 
identify a cell within a location area. 

Neighbor CI field is a conditional field and it is included only if CellldType is set 1 ' and CI value of the given 
cell is available. 

Range: - 65535 

Neighbor BSIC 

This field indicates the BSIC (Base Station Identity Code of the base station). 

BSIC field is conditional and it is included only if CellldType is set X)'. 
Range: 0-63 

Neighbor BCCH Carrier 

This field indicates the absolute RF channel number of the neighbor base station. BCCH carrier field is 
conditional and it is included only if CellldType is set D'. 

Range: 0-1023 

Neighbor RX Level 

RX Level field includes the received signal strength on the neighbor BTS. 

The RX Level is expressed in 2 dBm steps within the range -150 .. -24 dBm. 
Range: .. 63 

Neighbor Frame Number 

This field indicates the calculated value of the neighbor BTS's frame that would have been received at the same 
time or immediately after as the last measured frame from the reference BTS. This field is optional. 

Range: 0-2715647 

Neighbor Time Slot 

Neighbor Time Slot indicates the time slot relative to which the LMU reports the serving BTS measurements. 
This field is mandatory. 

Range: to 7 

NOTE: If the LMU does not know timeslot scheme, the LMU reports the used timeslot. The LMU can only report 
results based on one time slot (N) or two time slots (N and Nh-4). If the LMU knows timeslot scheme, the 
LMU can make measurements from several timeslots and reports that the used timeslot is zero (and 
makes correction). 

ATD/RTD Value 

This field indicates the measured ATD/RTD value between the receptions of signals from the reference and the 
neighbor BTS. This ATD/RTD value is the difference in reception of signal (the starting moment of time slot) 
from reference BTS compared to the signal (next starting moment of a time slot) from the neighbor BTS (i.e. this 
value is always positive). This field is mandatory. The reporting resolution of ATD/RTD value is 0.005 micro- 
seconds. 

Range: ...923200 

NOTE: The reported ATD/RTD value may be based on some filtering or estimation algorithm. I.e. the reported 
value is not the last measurement result, it is the best estimate of real RTD value at the time of last 
measurement. 

ATD/RTD Quality 



£75/ 



3GPP TS 04.71 version 7.3.0 Release 1998 44 ETSI TS 101 725 V7.3.0 (2001-06) 

ATD/RTD Quality field includes the quality of reported RIT measurement. This ATD/RTD Quality field can be 
e.g. used to evaluate the reliability of RIT measurements in the SMLC. ATD/RTD quality is defined as 

ATD/RTD Quahty = ^J e]^X - juf \ = Std of reported ATD/RTD value, 

where X is the reported ATD/RTD value and fl = E\x\ is its expectation value. The reporting resolution of 
ATD/RTD Quality is defined by ATD/RTD Quality resolution field. 

Range: to 63 

This field is mandatory. 

ATD/RTD Change 

This field indicates the first time derivative of the ATD/RTD value between the receptions of signals from the 
reference and the neighbor BTS. This value is based on measurements made during Monitor Period, if the 
monitoring period is provided. Otherwise it is the best estimate of the ATD/RTD Change value at the time of last 
ATD/RTD measurement. The range is -0.1 ... 0.1 ppm and resolution is 0,00005 ppm. 

Range: -2000 ...2000 

ATD/RTD Change Quality 

ATD/RTD Change Quality field includes the quality of reported ATD/RTD Change. This ATD/RTD Change 
Quality field can be e.g. used to evaluate the reliability of RIT measurements in the SMLC. ATD/RTD Change 
Quality is defined as 

ATD/RTD Change Quality = ^JE^X-JUy\= Std of reported ATD/RTD Change value, 

where X is the reported ATD/RTD Change and fj. = E\x\ is its expectation value. The reporting resolution of 
ATD/RTD Change Quality is defined by ATD/RTD Change QuaUty resolution field. 

Range: to 63 

This field is mandatory. 

A.2.3 RIT Measurement Stop Message 

The RIT Measurement Stop is a message from the SMLC to the LMU. It is sent when the SMLC wants the LMU to 
stop doing RIT measurements and reporting them. It contains the following information elements. 

Table A.3: RIT Measurement Stop message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type A.2.3. 1 .1 


M 



A.2.3. 1 RIT Measurement Stop Message Information Elements 
A.2.3. 1.1 1 Message type IE 

This IE contains the type of the message. This IE is mandatory. 
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A.2.4 RIT Measurement Error Message 

The RIT Measurement Error is a message from the LMU to the SMLC. It is sent any time when the LMU can not 
perform RIT measurements asked for in the RIT Measurement Request. This message can be returned in return result 
(after reception of measurement command) or as separate message (during periodic measurement). It contains the 
following information elements. 

Table A.4: RIT Measurement Error message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type A.2.4. 1 .1 


M 


Error Type 


RIT Error Type A.2.4.1. 2 


M 


RIT Error 


RITErrorA.2.4.1.3 


M 



A.2.4.1 RIT Measurement Error Message Information Elements 
A.2.4.1 .1 Message type IE 

This IE contains the type of the message. This IE is mandatory. 

A.2.4.1. 2 RIT Error Type IE 

This IE indicates whether the error is temporarily (e.g. GPS reset) or permanent errors. Permanent error requires 
actions in SMLC, temporarily error informs that LMU can not send results temporarily (but it is expected to recover 
without any actions from SMLC). 

X)' = Permanent error 

1 ' = Temporarily error 

A.2.4.1. 3 RIT Error IE 

The purpose of the RIT Error IE is to provide the indication of error and the reason for it, when the LMU can not report 
required RIT results. This IE is mandatory. This IE has the following fields. 

Error Reason 

This field indicates the reason for error. 

X)': There were no neighbor BTSs to be received. 

1 ': No ATD measurements were possible, since the common reference clock was not available. 

2': Requested type of measurements is not supported. 

3': Undefined error. 
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Annex B (informative): 
TOA messages 

B.1 IVIessages 

The following TOA related messages are exchanged between the SMLC and the LMU. 

1) Perform TOA Measurement (MLC->LMU) 

2) TOA Measurement Result (response to 1. LMU-> MLC) 

B.1 .1 Perform TOA IVIeasurement IVIessage 

The Perform TOA Measurement is a message from the SMLC to the LMU. As a response to it the LMU measures Time 
Of Arrival of MS transmitted signals. The signal characteristics are specified in the message. It contains the following 
information elements. 

Table B.1 : Perform TOA Measurement message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type IE 3.1 


M 


Measurement Device Info 


Measurement Device Info 
IE 3.2 


M 


Channel Description 


Channel Description IE 
3.3 


M 


Signal Description 


Signal Description IE 3.4 


M 


Timing Description 


Timing Description IE 3.5 


M 


Measurement Options 


Measurement Options IE 
3.6 






B.1 .2 TOA IVIeasurement Result Message 

The TOA Measurement Result is a message from the LMU to the MLC. It is a response to the Perform TOA 
Measurement message and contains the following information elements. 

Table B.2: TOA Measurement Result message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type IE 3.1 


M 


Number of Measurement Devices 


Number of Measurement 
Devices IE 3.7 


M 


Timing Info 


Timing Info IE 3.8 


M 








The following is repeated "Number 
of Measurement Devices" times 






Measurement Device ID 


Measurement Device ID 
IE 3.10 


M 


Measurement Info 


Measurement Info IE 
3.11 


M 


Number of Peaks 


Number of Peaks IE 3.12 


M 


Ttie following is repeated "Number 
of Peaks" times 






Measured TOA 


Measured TOA IE 3.13 


M 


TOA Quality 


TOA Quality IE 3.14 


M 
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B.2 Information element encodings 
B.2.1 Message Type IE 

This IE contains the type of the message. 
Range: - 255 

B.2.2 Measurement Device Info IE 

This IE indicates the LMU Measurement Devices that are addressed with the message. (One physical LMU may contain 
several devices, e.g. an LMU co-located with a three sector site would normally contain three devices). It contains the 
following fields: 

Number of Measurement Devices 

This field indicates the number of LMU Measurement Devices that are addressed with the message. This field is 
mandatory. 

Range: 1-6 

The following field is repeated "Number of Measurement Devices" times. 

Measurement Device ID 

This field indicates the ID of the LMU Measurement Device. 

Range: -5 

B.2.3 Channel Description IE 

The purpose of the Channel Description IE is to inform the LMU about the physical channel used by MS. This IE 
contains the following fields: 

Frequency List Type 

This field describes the format of the frequency information. If both frequency list and index is provided then the 
LMU shall store the frequency list and its associated index. If only an index is provided the LMU shall use the 
associated frequency list. 

'0': Frequency list only 

'1': Frequency list and index 

'2': Frequency list index only 

Frequency list index 

This field identifies a frequency list either provided with this message or stored by the LMU. This field is present 
when "Frequency List Type" is equal to 1 or 2. 

Range: 0-31 

Number of ARFCNs 

This field indicates the number of frequencies used by MS. This field is present if "Frequency List Type" is 
equal to or 1 . 

Range: 1-64 

The following field is repeated the number of times indicated by the "Number of ARFCNs" field. 

ARFCN 

This field indicates the absolute radio frequency number. This field is present if "Frequency List Type" is equal 
toOor 1. 

Range: 0-1023 
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Hopping 

This field indicates if frequency hopping is used. This field is mandatory. 

X)': No hopping 
1': Hopping 

MAIO 

This field indicates the Mobile Allocation Index Offset used in the frequency hopping algorithm (see 
3GPP TS 05.02). This field is present if Hopping='l'. 

Range: 0-63 

HSN 

This field indicates the Hopping Sequence Number used in the frequency hopping algorithm (see 
3GPP TS 05.02). This field is present if Hopping='l'. 

Range: 0-63 

Frame Number 

This field indicates the Frame Number modulo 84864 of the first burst expected from the MS. It is used in the 
frequency hopping algorithm (see 3GPP TS 05.02). This field is present if Hopping='l '. 

Range: 0-84863 

Channel Type 

This field indicates the channel type. This field is mandatory. 

W: TCH/F 

7': TCH/H SCN=0 

3': TCH/H SCN=1 

Number of Bursts 

This field indicates the number of bursts to measure TOA on. This field is mandatory. The field is coded as 
follows 

Value Number of Bursts 

5 

1 10 

2 20 

3 40 

4 70 

5 140 

6 280 

7 560 



B.2.4 Signal Description IE 



The purpose of the Signal Description IE is to inform the LMU about the signal transmitted by MS. It contains the 
following fields: 

Burst Type 

This field contains the burst type transmitted by MS. 

X)': Access Burst 
1 ': Normal Burst 
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Handover Reference 

This field contains the handover reference number which together with BSIC completely defines the data 
portion of the access burst. This field is present when Burst Type = W. 



BSIC 



TSC 



Range: -255 

This field indicates the BSIC (Base Station Identity Code) which together with Handover Reference Number 
defines the data portion of an access burst. This field is present when Burst Type= X)'. 

Range: 0-63 

This field indicates the Training Sequence Code used by MS. This field is present when Burst Type=T'. 
Range: 0-7 

B.2.5 Timing Description IE 

This IE provides information about the predicted arrival time of MS signals. It contains the following fields: 

Time Reference 

This field indicates the used clock reference. This field is mandatory. 

'0': GPS time 
'1': GSM time 
'2'-'3': Reserved for future use 

GPS Start Time 

This field indicates the predicted signal arrival time expressed in GPS time. The signal arrival time (TOA) is 
defined as the start point of a time slot. It is counted in units of 4 micro-second modulo 60s. To remove any 
ambiguity, let RT denote the reception time, ST denote the start time, and T an arbitrary time. Then if 

1) (ST-RT) mod 60s <= 40s 

then the indicated start time is the next time when T mod 60s is equal to ST. 

It is possible that a request arrives late so that 1) is not fulfilled but before all bursts have been transmitted. It 
is in such a case possible to perform measurements on the remaining bursts if condition 

2) (RT-ST) mod 60s < A. 

is fulfilled. Here A denotes the length of the complete measurement interval. It can be derived from the fields 
Channel Type and the Number of Bursts. 

Should however neither of 1) or 2) be fulfilled then the request arrived too late and the bursts were missed. 

This field is present when Time Reference='0' 

Range: - 14,999,999 

GPSSV 

This IE identifies a GPS clock SV (Space Vehicle) used for time stamping. Value means that all available GPS 
sources should be used for deriving a time stamp. This field is present if Time Reference = '0'. 

Range: 0-31 

BCCH 

This field indicates the ARFCN (BCCH) of the BTS whose clock is used as reference for Start Time. This field 
is present when Time Reference='r. 

Range: 0-1023 

BSIC 
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This field indicates the Base Station Identity Code of the BTS whose clock is used as reference for Start Time. 
This field is present when Time Reference='r. 

Range: 0-63 

GSM Start Time 

This field indicates the predicted signal arrival time expressed in GSM time. It is expressed as Frame Number 
FN modulo 42432, Time slot Number TN and Bit Number BN. The reference point for signal arrival time (TOA) 
is defined as the start point of a time slot. The start time can encode only an interval of time of 42 432 frames, 
that is to say around 195.8 seconds. To remove any ambiguity, let RFN denote the frame number at reception, 
and FN' denote an arbitrary frame number. Then if 

1) (FN-RFN) mod 42432 < 31623 

then the indicated starting FN is the next time when FN' mod 42432 is equal to FN. 

It is possible that a request arrives late so that 1) is not fulfilled but before all bursts have been transmitted. It 
is in such a case possible to perform measurements on the remaining bursts if the condition 

2) (RFN-FN) mod 42432 < A. 

is fulfilled. Here A denotes the length of the complete measurement interval. It can be derived from the fields 
Channel Type and the Number of Bursts. 

Should however neither of 1) or 2) be fulfilled then the request arrived too late and the bursts were missed. 

This field is present when Time Reference='r. It contains the following subfields: 

FN (mod 42432): 

Range: - 42432 

TN: 

Range: 0-7 

BN: 

Range: 0- 156 

Start Time Uncertainty 

This field indicates the uncertainty in the arrival of the signal from MS. Expressed in GSM bit periods (i.e. 48/13 
micro-seconds). The burst is expected to arrive in the interval 

[Start Time - Start Time Uncertainty, Start Time + Start Time Uncertainty] 

This field is mandatory. The field is coded as follows. 

Value Uncertainty 

2 

1 3 

2 4 

3 5 

4 7 

5 10 

6 13 

7 17 

8 20 
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9 25 

10 35 

11 45 

12 55 

13 65 

14 90 

15 140 



B.2.6 Measurement Options IE 

This IE indicates options for TOA measurement. It contains the following fields. 

Method 

This field defines the TOA algorithm to be used by LMU. A value of zero indicates that a default algorithm may 
be used. Remaining values are vendor specific. This field is mandatory. 

Range: 0-7 

Environment Characterization 

This field indicates the expected multipath environment. This field is mandatory. 

'0': possibly heavy multipath and NLOS conditions (e.g. bad urban or urban) 
'1': no or light multipath and usually LOS conditions (e.g. suburban or rural) 
'2': not defined or mixed environment 
'3': reserved 
'4': reserved (i.e. several values should be reserved) 

Measurement Type 

This field indicates whether LMU shall include an estimate of the Time of Arrival (TOA) and/or Angle of 
Arrival (AOA) with the measurement result. 

'0': Report TOA only 

T': Report AOA only 

'2': Report TOA and AOA 

B.2.7 Number of Measurement Devices IE 

This IE indicates the number of LMU Measurement Devices that are reporting with the message. 
Range: 1-6 



B.2.8 Timing Info IE 



This IE provides information about the used clock source for TOA measurement. It contains the following fields: 
Time Reference 
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This field indicates the used clock reference. This field is mandatory. 

X)': GPS time 

'1': GSM time 

'2'-3': Reserved for future use 

BCCH 

This field indicates the ARFCN (BCCH) of the BTS whose clock is used as clock reference. This field is present 
when Time Reference='r. 

Range: 0-1023 

BSIC 

This field indicates the Base Station Identity Code of the BTS whose clock is used as clock reference. This field 
is present when Time Reference='r. 

Range: 0-63 

B.2.10 Measurement Device ID IE 

This IE indicates the ID of the reporting LMU Measurement Device. 
Range: -5 

B.2.1 1 Measurement Info IE 

This IE indicates additional information related to the signal measurement. 

Method 

This field indicates the used method for TOA measurement. This field is mandatory. 

Range: 0-7 

Diversity 

This field indicates if diversity was used for measurements. This field is mandatory. 

'0': Diversity was not used. 
'1': Diversity was used. 

IVIeasured Number of Bursts 

This field indicates the number of bursts used for TOA measurement. It is expressed as a ratio N = (number 
measured)/(number requested). This field is mandatory. It is coded as follows. 

< N < 1/7 

1 1/7 < N < 2/7 

2 2/7 < N < 3/7 

3 3/7 < N < 4/7 

4 4/7 < N < 5/7 

5 5/7 < N < 6/7 

6 6/7 < N < 1 

7 N=l 

Angle of Arrival 

This field indicates the Angle of Arrival in units of 0.1 degrees. This field is optional. 
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Range: - 3599 

AOA Uncertainty 

This field indicates the quahty of Angle of Arrival (AOA) estimate in units of 0.1 degrees. It is defined as 
follows. Let © denote the estimated AOA, ©o denote the true AOA, and r denote the uncertainty. 
Then Prob(l©-©ol < r) = 67%, i.e. with 67% confidence the true AOA Hes in the interval [©-r, ©+r]. 
The uncertainty r, expressed in degrees, is mapped to a number K, with the following formula: 



C(il + xf-l) 



with C = 0.446 and x = 0,25. With < K < 30, a useful range between 0.1 degrees and 360 degrees is achieved 
for the uncertainty. K is the value being sent. A value of 3 1 means that the measurement failed. This field is 
optional. 

Range: 0-31 

B.2.12 Number of Peaks IE 

This IE indicates the number of peaks (i.e. TOA values) reported. 
Range: - 4 

B.2.13 Measured TOA IE 

This IE indicates the absolute TOA value (modulo the duration of a TDMA frame) determined by LMU. Expressed in 
units of 0.004 micro-seconds relative to the starting time. 

Range: -131072 -H-131071 

B.2.14 TOA Quality IE 

This IE indicates the TOA quality determined by LMU. It contains the following fields: 

TOA Uncertainty 

This field indicates the uncertainty of the TOA estimate. It is defined as follows. Let T denote the estimated 

TOA, To denote the true TOA, and r denote the uncertainty. Then Prob(IX-Xol < r) = 67%, i.e. with 67% 

confidence the true TOA lies in the interval [T-r, X+i]. The uncertainty r, expressed in nanoseconds, is mapped 
to a number K, with the following formula: 



C(il + xf-l) 



with C = 25 and x = 0. 12. With < K < 62, a suitably useful range between 3 ns and 28 )J,s is achieved for the 
uncertainty. A value of 63 means that the measurement failed. This field is optional. 

Range: 0-63 

SNR Estimate 

This field indicates the estimated Signal To Noise ratio. Values are expressed in steps of 1 dB ranging from -30 
to + 33. This field is optional. 

Range: 0-63 

TOA Signal Strength 

This field indicates the estimated Signal Strength. Values are expressed in steps of 2dBm from -150 to -24 dBm. 
This field is optional. 

Range: - 63 
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Annex C (informative): 
Status IVIessages 

C.1 Introduction 

This annex describes the contents of messages related to the status of an LMU. 

C.2 IVIessages 

The messages below are considered to be transported between the SMLC and the LMU. 

C.2.1 Status Query IVIessage 

The Status Query is a message from the SMLC to the LMU. It contains the following information elements. 

Table C.1 : Status Query message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type C.2.1 .1.1 


M 



C.2.1 .1 Status Query Message Information Elements 
C.2. 1.1.1 Message Type IE 

This IE contains the type of the message. This IE is mandatory. 

C.2.2 Status Query Result IVIessage 

The Status Query Result is a message from the LMU to the SMLC. It contains the following information elements. 

Table C.2: Status Query Result message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type 5.2.1.1 


M 


Time 


Time C.2.2.1.2 


M 


RIT Status 


RIT Status C.2.2.1. 3 


M 


TOA Status 


TOA Status C.2.2.1. 4 


M 


O&M Status 


O&M Status C.2.2.1. 5 


M 



C.2.2.1 Status Query Result Message Information Elements 
C.2.2.1 .1 Message Type IE 

This IE contains the type of the message. This IE is mandatory. 

C.2.2.1.2 Time IE 

This IE contains the time stamp for this message. This IE is mandatory, and it contains the following fields: 

Reference LAC 

This field indicates the Location Area Code of the reference BTS. The purpose of the Location Area Code is to 
identify a location area. 
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Range: - 65535 

Reference CI 

This field indicates the Cell Identity value of the reference BTS. The purpose of the Cell Identity value is to 
identify a cell within a location area. 

Range: - 65535 

Reference Frame Number 

This field indicates the frame number of the last measured burst from the reference BTS. 

Range: 0-2715647 

C.2.2.1.3 RIT Status IE 

The purpose of the RIT Status IE is to inform the SMLC about the status of on-going RIT related activity. This IE is 
mandatory, and it contains the following fields: 

RIT Jobs 

This field indicates the number of on-going RIT related jobs, i.e. the number of neighbor BTSs that are tried to 
be measured. Notice that means that no RIT related activity is on-going. 

Range: 0-63 

C.2.2.1.4 TOA Status IE 

The purpose of the TOA Status IE is to inform the SMLC about the status of on-going TOA related activity. This IE is 
mandatory, and it contains the following fields: 

TOA Jobs 

This field indicates the number of on-going TOA related jobs, i.e. the number of MSs that are tried to be 
measured. Notice that means that no TOA related activity is on-going. 

Range: 0-63 

C.2.2.1.5 O&M Status IE 

The purpose of the O&M Status IE is to inform the SMLC about the status of on-going O&M related activity. This IE is 
mandatory, and it contains the following fields: 

O&M Jobs 

This field indicates the number of on-going O&M related jobs. 

Range: 0-63 

C.2.3 Status Update Message 

The Status Update is a message from the LMU to the SMLC. It contains the following information elements. 

Table C.3: Status Response message content 



Information element 


Type/Reference 


Presence 


Message Type 


Message Type C.2.3. 1 .1 


M 


Reason for Status Update 


Reason for Status 
Update C.2.3.1. 2 


M 


Time 


Time C.2.2.1.2 


M 


RIT Status 


RIT Status C.2.2.1.3 


M 


TOA status 


TOA Status C.2.2.1.4 


M 


O&M Status 


O&M Status C.2.2.1.5 


M 
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C.2.3.1 Status Update Message Information Elements 
C.2.3.1 .1 Message Type IE 

This IE contains the type of the message. This IE is mandatory. 

C.2.3.1 .2 Reason for Status Update IE 

This IE contains the reason for sending this Status Update Message. This IE is mandatory, and it contains the following 
fields: 

Reason Code 

This field indicates Reason code for sending this Status Update Message. 

X)': power up (no knowledge about previous states) 

1 ': S W reset, unsuccessful recovery 

2': SW reset, successful recovery 

3': unknown selfdiagnosis error 

'4': unreliable timebase error 

'5': periodic status report, normal operation 
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Annex D (informative): 
Change History 



Meeting# 


CR 


Rev 


New Version 


Subject/Comment 


SMG#29 






7.0.0 


Approved at SMG#29 as Release 98 


SMG#30bis 


A001 




7.1.1 


Addition of further LCS functionality in GSM Release 98 


SMG#32 


A003 




7.2.0 


IVIodifications to O&M operations to adapt to 3GPP TS 12.71 and some 
minor editorial corrections 


GP-05 


A005 


2 


7.3.0 


Modifications of quality information 


GP-05 


A009 


1 


7.3.0 


ASN.1 References update 
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